lkml.org 
[lkml]   [2010]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: 2.6.36 io bring the system to its knees
    From
    On Thu, Oct 28, 2010 at 2:33 PM, Aidar Kultayev <the.aidar@gmail.com> 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.

    On Thu, Oct 28, 2010 at 2:33 PM, Aidar Kultayev <the.aidar@gmail.com> wrote:
    > Another way I see these delays, is when I leave system overnight, with
    > ktorrent & juk(stopped) in the background. It takes some time for
    > WM(kwin) to work out ALT+TAB the very next morning. But this might be
    > because the WM(kwin & its code) has been swapped out, because of long
    > period of not using it.

    Yeah, that's probably paging overhead.

    P.S. Can you please upload latencytop output somewhere and post an URL
    to it so other people can also see it?


    \
     
     \ /
      Last update: 2010-10-28 13:51    [W:4.873 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site