Skip to content

[FEATURE] Fine-Grained VFS Locking for SMP Scalability #18531

@Sumit6307

Description

@Sumit6307

Is your feature request related to a problem? Please describe.

Yes. As NuttX expands its footprint into modern multi-core microcontrollers (e.g., dual-core ESP32, multi-core SMP RISC-V architectures), the Virtual File System (VFS) is becoming a concurrency bottleneck.

Currently, the VFS relies on relatively coarse-grained locks. When multiple cores attempt simultaneous I/O operations (such as traversing directory paths or opening independent sockets/devices mapped in /dev/), they contend for the same global or broad locks. This limits parallel I/O throughput and defeats the performance benefits of Symmetric Multiprocessing (SMP) hardware, especially in heavy networking or logging applications.

As a prospective Google Summer of Code (GSoC) 2026 contributor, I am proposing a project to modernize VFS concurrency controls specifically for SMP environments, while strictly maintaining the zero-overhead footprint for traditional single-core chips.

Describe the solution you'd like

I propose implementing fine-grained locking and selective lock-free data structures within the VFS (fs/vfs/). The planned solution includes:

  • Reader-Writer Locks for VFS: Replacing monolithic mutexes with Reader-Writer locks (pthread_rwlock_t equivalents inside the kernel) for inode lookups and directory traversal. This allows multiple cores to read filesystem metadata simultaneously while safely blocking on rare writes (creation/deletion).
  • CONFIG_SMP Strict Isolation: Wrapping all new locking primitives and concurrent data structures in #ifdef CONFIG_SMP. If a user builds for a standard 8-bit or 16-bit uniprocessor, these locks will compile out to standard fast mutexes or no-ops, strictly enforcing self-compatibility (Rule 1.10) and preventing binary size bloat.
  • Lock-free Data Structures: Investigating and introducing specific lock-free mechanisms (like RCU-lite) for highly-contended kernel lists (e.g., the open file list or mount points) if they prove necessary and footprint-friendly.
  • Hardware Benchmarking: Developing and running SMP concurrency benchmarks (apps/fs/fstests) on a dual-core hardware target (like the ESP32) to mathematically prove the I/O throughput improvements and submit the regression testing logs alongside the PRs.

The project will proceed in atomic increments to ensure strict code review and prevent any breaking changes to the 360+ existing board configurations.

Describe alternatives you've considered

  • Alternative 1: Leaving the VFS lock mechanism as-is and optimizing individual file system drivers (like FAT or LittleFS). However, this does not solve contention at the VFS /dev/ abstraction layer, which affects network sockets and generic drivers alike.
  • Alternative 2: Adopting full Read-Copy-Update (RCU) across the entire kernel. This is likely too heavy for the memory constraints of NuttX. Therefore, the chosen alternative isolates these upgrades specifically to the VFS and CONFIG_SMP builds.

Verification

  • I have verified before submitting the report.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions