Sumit6307 opened a new issue, #18531: URL: https://github.com/apache/nuttx/issues/18531
### 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 - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
