Re: Interactivity issue in 2.6.25-rc3

["Ray Lee" <ray-lk@madrabbit.org>]

On Fri, Feb 29, 2008 at 7:57 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
>  * Ray Lee <ray-lk@madrabbit.org> wrote:
>
>  > But it's good to keep in mind that the scheduler can't do anything
>  > about slowdowns due to tasks being swapped out or waiting on reads
>  > from the disk. I mention this as shortly after CFS got into mainline,
>  > something changed in the VM that seems to make my system spend a lot
>  > more time in IO wait, causing the system to be much less responsive
>  > than it used to be.
>  >
>  > Unfortunately it seems to be dependent upon the history of what tasks
>  > I've run and their memory usage, so it's been hard to come up with a
>  > reproducible test case (well that and a complete lack of time). All I
>  > can say is that I've seen what you've reported as well, though it had
>  > nothing to do with using any 3d applications, just a browser, editor,
>  > gcc, etc.
>
>  what does latencytop say about those delays, what causes them? It should
>  be able to capture all sorts of latency sources in the system.

Ah, thanks for the reminder. The last I tried it, it didn't show
anything other than scheduler: waiting on cpu, but using a git clone
version captured this almost immediately:

EXT3: Waiting for journal access                  2261.1 msec         15.0 %
Writing a page to disk                            112.4 msec          0.7 %
Scheduler: waiting for cpu                         57.9 msec         17.7 %
default_wake_function __queue_work call_usermodehe  5.9 msec          0.1 %
Waiting for event (poll)                            5.0 msec         37.5 %
Waiting for data on unix socket                     5.0 msec          2.1 %
Userspace lock contention                           4.9 msec         23.5 %
Waiting for TTY data                                4.9 msec          0.3 %
Sending TCP/IP data                                 4.9 msec          0.0 %

I'm running postgresql in the background on this system and it does
regular sync's, so perhaps that's related?

It doesn't look like latencytop saves the trace data anywhere other
than my eyes? I'll hack in a log and see what else it gets.