Sumit6307 commented on issue #18531: URL: https://github.com/apache/nuttx/issues/18531#issuecomment-4064936319
> [@jingfei195887](https://github.com/jingfei195887) [@Sumit6307](https://github.com/Sumit6307) may we close this proposal? > > [@Donny9](https://github.com/Donny9) do you have some benchmark comparing the FS performance on SMP before and after that commit? > > [@Sumit6307](https://github.com/Sumit6307) how did you come up with this idea? Did you assume NuttX had a bad performance without doing benchmark and without looking the code base? :-) > > [@linguini1](https://github.com/linguini1) [@raiden00pl](https://github.com/raiden00pl) [@xiaoxiang781216](https://github.com/xiaoxiang781216) I think something we should have is some performance metrics. It could be executed from time to time and every time a new version is realized. Similar what we do when a new rc version is realized (showing the size of the binary), but it should be done automatically by the CI. Probably it should require some modification on CI to support it. [@simbit18](https://github.com/simbit18) [@lupyuen](https://github.com/lupyuen) any idea how can we do it? Hi @acassis and @jingfei195887 , Thank you for the feedback and for pointing out the existing implementation! @jingfei195887 , you are absolutely right. I missed the rwsem integration in fs/inode/fs_inode.c during my initial review of the codebase. I see now that the transitions from monolithic mutexes to reader-writer semaphores have already been addressed. @acassis , to be honest: I came up with the idea based on general research into VFS scalability bottlenecks in SMP systems (like Linux and other RTOSs), but I made the mistake of assuming NuttX still faced these specific issues without first benchmarking the latest master branch. I should have established a performance baseline before proposing the solution. I appreciate you calling that out! Since the fine-grained locking is already implemented, I agree that we can close this proposal in its current form. However, I am very interested in your comment regarding automated performance metrics in CI. @Donny9 mentioned not having clear benchmark comparisons for the FS performance on SMP, and I would love to help solve that. Would you be open to me pivoting my GSoC 2026 interest toward developing an automated FS/SMP benchmarking suite for the NuttX CI? This would ensure that future changes have mathematical proof of their impact and help catch performance regressions automatically. If this aligns with the project's goals, I can start looking into how to integrate these metrics with the current CI setup. -- 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]
