Ingo Molnar <mingo@elte.hu> wrote:
>
>
> well, i took out the interactivity improvements from the 2.5.59-E6
> scheduler patch, to keep the pure HT-scheduler bits only, and havent added
> them back since. The two patch-sets (interactivity, and HT scheduler)
> interact heavily, so i did not post the patch separately, but here it goes
> as-is, against 2.5.64 - does it help your interactivity problems on UP
> setups?
Ah, this is the patch I thought I was testing last time ;) A bit more careful
this time:
- The tbench-starves-everything-on-uniprocessor problem (well, I'd have to
say it is a bug) is fixed.
When running a compilation against a `tbench 4' one would expect the
compilation to be slowed down by maybe 4x. It seems a little slower than
that, but it is in that ballpark. At least the compilation makes _some_
progress now.
- The large performance shift with `contest io_load' is still there.
This test times how long it takes to compile a kernel in the presence of
massive streaming writeout to the same filesystem.
2.5.64, UP, !preempt, ext3:
Finished compiling kernel: elapsed: 409 user: 107 system: 11
Finished io_load: elapsed: 409 user: 2 system: 37 loads: 16810
Finished compiling kernel: elapsed: 283 user: 107 system: 10
Finished io_load: elapsed: 286 user: 1 system: 17 loads: 7990
2.5.66+sched-2.5.64-A4, UP, !preempt, ext3:
Finished compiling kernel: elapsed: 910 user: 108 system: 12
Finished io_load: elapsed: 912 user: 4 system: 75 loads: 35210
Finished compiling kernel: elapsed: 940 user: 108 system: 12
Finished io_load: elapsed: 940 user: 4 system: 78 loads: 36510
The compilation took twice as long, and the streaming write made much
more progress.
Given that a monster `dd if=/dev/zero' takes only a few percent CPU
anyway, it is quite odd that this is happening.
Regardless of the fairness issue we want to maximise CPU utilisaton in
this workload. The above figures show that the total CPU utilisation has
fallen from
409 / (107+11+4+75) = 48% CPU
and 283 / (107+10+1+17) = 48% CPU
down to
910 / (108+12+4+75) = 22% CPU
and 940 / (108+12+4+78) = 21% CPU
which is quite bad.
I cannot explain this - why so much idle time? It seems to happen with
ext2 as well, so it may not be the weird interaction between kjournald, the
CPU scheduler and the IO scheduler which I initially suspected. Poor me.
- On the X server problem: The patch pretty much fixes it up. I have to
work pretty hard to make the UI flip into sucky mode, and it is much less
severe. I'd say it it acceptable.
Renicing X to -10 makes it significantly better. Text under moved
windows gets redrawn promptly. But renicing X is not a very adequate
solution in my experience - I've found that when the email client goes off
to parse a 1000-message folder the scheduler can decide to penalise it, and
the application freezes up for some time.
Overall, yep, good patch and we should run with it. I need to work out what
on earth has happened to the IO load balancing. We only got that working
properly a few days back.
-
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 : Fri Mar 07 2003 - 22:00:31 EST