Messages in this thread | | | Date | Mon, 28 Mar 2011 21:48:57 +0200 | From | Jan Kara <> | Subject | Re: [performance bug] kernel building regression on 64 LCPUs machine |
| |
On Tue 22-03-11 13:46:06, Jeff Moyer wrote: > Jan Kara <jack@suse.cz> writes: > > > Jeff, I suppose the log files of fs_mark processes are on the same > > device as the test directory, aren't they - that might explain the > > flusher thread doing IO? The patch below > > No. My test environments are sane. The file system is on a completely > separate disk and it is unmounted and remounted in between each run. > That should take care of any lost flushes. OK, I understand but let me clear out one thing. What fs_mark seems to be doing is: for given number of iterations { (-L option, default 1) fork each thread { start timer for i = 1 .. 10000 { (could be changed by option -n) write file i } stop timer for i = 1 .. 10000 { unlink file i } write statistics to log file exit } read all log files, write combined results to another log file }
I see from blktrace data that indeed you are running more than one iteration of the fs_mark process so the problem I was wondering about is whether unlinking or writing of log files cannot interefere with the IO happening while the timer is running.
Now log files are rather small so I don't really think they cause any problem but they could be the data flusher thread writes - they are stored in the current directory (unless you use -l option). So I my question was aiming at where these files are stored - do you specify -l option and if not, what is the current directory of fs_mark process in your setup?
I think unlinks could possibly cause problems and that's why I suggested we add sync() to the parent process before it runs the next iteration...
> Did you receive my last couple of private emails commenting on the trace > data? Yes, I did get them. I'll reply to them in a while.
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR
| |