Tag Info

New answers tagged


As Sankalp mentioned, pdflush thread is not involved with writes on a file with O_SYNC flag set. It happens in thread context. To get the exact code path taken by kernel you could use ftrace to trace write syscall. I am able to test the same and documented here on my blog


It is not necessary for flushing to happen in the context of pdflush thread. In the case of O_SYNC and the fsync call, the flushing happens in the context of the thread invoking the write/sync system call. The code path in the o_sync case goes roughly as: __vfs_write -> (f_op->write_iter)/generic_file_write_iter -> generic_write_sync -> (f_op->fsync) -> ...


OK, it looks like the subject of this question is a furphy ... memory mapped I/O (done correctly) will be as fast as the processor can do it for the hardware being accessed and there will be no overhead for doing this from user mode as opposed to kernel mode (i.e. there is no "write from the userspace to kernel"). However, you still have to think about what ...


For Linux: opensnoop from Brendengreg's perf-tools should do the job https://github.com/brendangregg/perf-tools For Solaris Dtrace is there anyways


On Linux you can use strace to monitor these kind of events: strace -f -p <PID> -e trace=file On Solaris, you can use dtrace. Have a look at the DTraceToolkit tool opensnoop, which is installed by default on Solaris 11 under /usr/dtrace/DTT/Bin/opensnoop. /usr/dtrace/DTT/Bin/opensnoop -p <pid>

Top 50 recent answers are included