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.
On Sat, Oct 05, 2002 at 07:15:49PM -0700, Andrew Morton wrote:
> 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.
As a mad guy who runs gnome on an ARM box virtually every day, and
compared the speed of gnome during startup and in operation with
traditional X applications, gnome is severely lacking in speed
and "snappyness".
Eg, a pure X setup starts up in less than 5 seconds. With gnome,
you're looking at around 30. Gnome 1.2 was slower than Gnome 1.4.
I haven't tested Gnome 2 yet.
Flipping around between workspaces is something I do regularly (6 of
them.) With a fairly old (1997) fvwm + fvwmpager + gnome 1.2 its
adequately fast - less than 1 second. With sawfish + gnome 1.4,
even the refresh of other applications is noticably slower, and with
fvwm + gnome 1.4 its unbearable (because the gnome panel is obtaining
a complete list of windows and clients with the X server grabbed, and
quering various properties - because fvwm isn't gnome-compliant, the
panel can't ask the wm.)
The start up of rxvt - less than 1 second. The start up of
gnome-terminal - around 15-20 seconds.
What I'm not saying here is that anything one thing sucks (except maybe
ARM on a desktop box running Gnome.) The point I'm trying to make is
that you can give the kernel as much "interactive" feel as you like, but
until user space gets It Right (tm), the kernel isn't really going to
make one blind bit of difference to the "feel" the user experiences.
I just wish someone would take away all the gnome developers high
performance machines and give them slow old 486's. 8)
(PS, before the "use the source" mob start running about, I'm a full time
kernel hacker. To get up to speed on gnome to fix this would require me
to leave the kernel for a considerable amount of time. This isn't going
to happen any time soon; there is only a certain number of hours in a day.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sunday 06 October 2002 04:15, Andrew Morton wrote:
> Rob Landley wrote:
> > And the work that matters for the desktop is LATENCY work.
>
> 100% true.
Not 100%.
First of all desktop work is driver work. Desktop users tend to get pissed
if their shiny new webcam or DSL does not work.
And thinks like the hotplugging subsystems are essential.
Handling of removable media still is less than optimal.
Then there's the issue of application startup. There's not enough
read ahead. This is especially sad, as the order of page faults is at
least partially predictable.
Another thing that sucks in desktop enviroments is displaying directories.
Asynchronous IO will somewhat help, but you can't do an asynchronous stat.
Now do this while a compiler is running. Deadline IO scheduling will help
but a real helper would be read ahead on directory, inode and multi file
level.
Regards
Oliver
> Then there's the issue of application startup. There's not enough
> read ahead. This is especially sad, as the order of page faults is
> at least partially predictable.
Is the problem really, fundamentally a lack of readahead in the
kernel? Or is it that your application is huge bloated pig?
With admittedly no evidence whatsoever, I suspect the latter is
really the root cause of this type of problem.
Ditto for the "takes me years to switch between desktops" ...
maybe it's just that RAM is full of utter garbage due to mindless
feature-bloat, so everything gets swapped out. If you're running
something like Netscape / Mozilla ... ;-)
I still think userspace is 90% of the problem here ...
M.
On Sunday 06 October 2002 17:19, Martin J. Bligh wrote:
> > Then there's the issue of application startup. There's not enough
> > read ahead. This is especially sad, as the order of page faults is
> > at least partially predictable.
>
> Is the problem really, fundamentally a lack of readahead in the
> kernel? Or is it that your application is huge bloated pig?
> With admittedly no evidence whatsoever, I suspect the latter is
> really the root cause of this type of problem.
Of course, but that's not an excuse for sucking more than necessary.
Application startup is a problem.
Regards
Oliver
On Sun, 2002-10-06 at 10:42, Russell King wrote:
> What I'm not saying here is that anything one thing sucks (except maybe
> ARM on a desktop box running Gnome.) The point I'm trying to make is
> that you can give the kernel as much "interactive" feel as you like, but
> until user space gets It Right (tm), the kernel isn't really going to
> make one blind bit of difference to the "feel" the user experiences.
>
> I just wish someone would take away all the gnome developers high
> performance machines and give them slow old 486's. 8)
The GNOME stuff is mostly userspace problems not kernel space, and some
of it is tool problems (lack of tools to lay binaries out so they stream
from disk, lack of tools to put all the fixups in the same few pages).
Gnome noticably improved when prelinking in gnu tools began to work
To do a meaningful kernel comparison you need to look at 2.2/2.4/2.5
with the same user space setup.
As to the 486's. There is optimisation work for gnome and especially
startup going on. Seems its a bit slow on those old legacy sparc64
contraptions ;)
On Sunday 06 October 2002 17:19, Martin J. Bligh wrote:
> > Then there's the issue of application startup. There's not enough
> > read ahead. This is especially sad, as the order of page faults is
> > at least partially predictable.
>
> Is the problem really, fundamentally a lack of readahead in the
> kernel? Or is it that your application is huge bloated pig?
Readahead isn't the only problem, but it is a huge problem. The current
readahead model is per-inode, which is very little help with lots of small
files, especially if they are fragmented or out of order. There are various
ways to fix this; they are all difficult[1]. Fortunately, we can call this
"tuning work" so it can be done during the stable series.
[1] We could teach each filesystem how to read ahead across directories, or
we could teach the vfs how to do physical readahead. Choose your poison.
--
Daniel