Rob Landley wrote:
>
> And the work that matters for the desktop is LATENCY work.
100% true.
You should resist any confusion between IO latency and CPU
scheduling latency. They really are worlds apart.
In a stock 2.4 kernel it is hugely rare for the kernel to stall
a ready-to-run task for longer than a monitor refresh interval,
so I continue to disbelieve any claims that the low-latency
and preemptivity patches make any difference in desktop use.
(And 2.5 improves on this a _lot_. The now-departed buffer LRU
and truncate list walks were the main culprits)
Any attempt to link IO priority with nice is probably doomed
to confused failure. It should be a clearly separated concept.
There are priority inversions everywhere, too.
I disagree with you on the new CPU scheduler. In my experience
it is significantly worse than the old one - a `make -j3' is
still sending interactive applications on extended lunch breaks.
Not that I have tried to tune this away.
Deadline scheduler is critical. As is a correct setting for
/proc/sys/vm/dirty_async_ratio and the soon-to-be-born
/proc/sys/vm/swappiness. These will boot up with sane values,
as much as is humanly possible.
It's not all kernel though. Application (KDE) startup is *slow*,
even when zero I/O is performed. Presumably because of the vtable
dynamic linking thing. I'm not sure how the prelinking work is
getting along, but the initial figures I saw on that indicated
that the benefit may not be sufficient.
-
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 : Mon Oct 07 2002 - 22:00:52 EST