Sumit6307 commented on code in PR #18607: URL: https://github.com/apache/nuttx/pull/18607#discussion_r2994303504
########## fs/vfs/fs_profile.c: ########## @@ -20,21 +20,36 @@ * ****************************************************************************/ -#ifndef __BOARDS_TRICORE_TC4DA_TRIBOARD_TC4X9_COM_INCLUDE_BOARD_H -#define __BOARDS_TRICORE_TC4DA_TRIBOARD_TC4X9_COM_INCLUDE_BOARD_H - /**************************************************************************** * Included Files ****************************************************************************/ #include <nuttx/config.h> +#include <nuttx/clock.h> +#include <nuttx/atomic.h> +#include "vfs.h" /**************************************************************************** - * Pre-processor Definitions + * Public Data ****************************************************************************/ +struct vfs_profile_s g_vfs_profile; + /**************************************************************************** - * Public Functions Definitions + * Public Functions ****************************************************************************/ -#endif /* __BOARDS_TRICORE_TC4DA_TRIBOARD_TC4X9_COM_INCLUDE_BOARD_H */ +void vfs_profile_start(FAR clock_t *start) Review Comment: > 1. I also recommend using **sched_note** for performance profiling. Avoid casually adding a variety of inconsistent performance interfaces to the system. Similar to Zephyr and Linux, they have clear, stable performance interfaces that have remained unchanged for many years: > > https://docs.zephyrproject.org/latest/services/tracing/index.html https://docs.kernel.org/trace/index.html > > 2. **sched_note** supports multiple backends and currently works with popular frameworks such as **ftrace** and **SystemView**. If you encounter performance issues, I think we can try optimization or add backend support for perf counter. > 3. VFS profiling cannot actually evaluate the actual write/read operations of the file system. In NuttX, sockets also pass through the VFS layer for network data transmission and reception. Could we implement similar performance evaluation within a specific file system? @anchao Thank you for this architectural insight! You are absolutely right—I had completely overlooked that socket traffic heavily passes through the VFS layer, which would inherently pollute any pure filesystem IO metrics we try to gather at this level. Your suggestion to use `sched_note` directly at the specific filesystem layer (e.g., inside FAT, LittleFS, RomFS) is a much better, industry-standard approach. It integrates cleanly with ftrace and SystemView, and tracing at the lower driver layer makes perfect sense for isolating true disk latency. I understand that this high-level VFS procfs approach is too inconsistent with Zephyr/Linux best practices. I am happy to abandon this PR given the strong community consensus in favor of `sched_note` instrumentation within the lower NuttX FS layers instead! -- 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]
