"Paolo Ciarrocchi" <ciarrocchi@linuxmail.org> wrote:
>
> for i in `seq 1 1 600`;
> do
> time sleep 1
> done;
>
> Then I've run it in background and then I've run 'dbench 32'.
> ...
> 0:01.16elapsed <-
> 0:02.84elapsed <-
Yup, that's expected. Normally the time command gets everything it needs
out of pagecache. Sometimes it needs to go to disk, and gets whacked by
other disk activity.
It can be regenerative too: `time' gets throttled in the page allocator.
This creates a larger time window in which the pages which it needs get
reclaimed. So it has to read things from disk. Which takes more time, so
more of its pages are reclaimed. And for each page which was reclaimed,
`time' needs to allocate memory, so it gets throttled again...
So you see it feeds on itself. What is normally a few millisecond delay
becomes a many-second delay.
There are probably games we can play in the page allocator to fix this up:
identifying heavy page allocators and preferentially stalling those.
Tricky to get right.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:36 EST