* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Oct 28, 2010 at 02:48:20PM +0300, Pekka Enberg wrote: > > On Thu, Oct 28, 2010 at 2:33 PM, Aidar Kultayev <the.aidar@xxxxxxxxx> wrote: > > > > > > if it wasn't picasa, it would have been something else. I mean if I kill > > > picasa ( later on it was done indexing new pics anyway ), it would have been > > > for virtualbox to thrash the io. So, nope, getting rid of picasa doesn't help > > > either. In general the systems responsiveness or sluggishness is dominated by > > > those io operations going on - the DD & CP & probably VBOX issuing whole bunch > > > of its load for IO. > > > > Do you still see high latencies in vfs_lseek() and vfs_fsync()? I'm not a VFS > > expert but looking at your latencytop output, it seems that fsync grabs > > ->i_mutex which blocks vfs_llseek(), for example. I'm not sure why that causes > > high latencies though it's a mutex we're holding. > > It does. But what workload does a lot of llseeks while fsyncing the same file? > I'd bet some application is doing really stupid things here. Seeking in a file and fsync-ing it does not seem like an inherently bad or even stupid thing to do - why do you claim that it is stupid? If mixed seek()+fsync() is the reason for these latencies (which is just an assumption right now) then it needs to be fixed in the kernel, not in apps. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>