On Monday 07 October 2002 09:56 am, Jesse Pollard wrote:
> In other words... don't swap.
"Don't swap this bit", anyway.
> If an application has to be swapped out, all
> bets are off on response time.
Alright, breaking the problem down into specific, bite-sized chunks, seeing
what's easily measurable, and then picking the lowest hanging fruit:
The frequency of mouse pointer stalls, and the worst case response time, is
probably something an automated benchmark could measure. (Z-order's a
tricker problem because the window manager's involved, but mouse stalls are
EASY to cause.)
On my laptop (with 256 megs ram and 256 megs swap). Open up 30 or 40
konqueror windows of a "this page looks interesting, I'll read it offline"
variety until memory's full and you're about 2/3 of the way into swap.
(KTimeMon makes this easy to see.) then do something swap-happy in the
background (including downloading a huge file, which causes disk cache to
grow and evict stuff, or of course running a big compile).
No matter how much ram the system has, with six desktops full of open windows
I can usually drive it DEEP into swap, without even picking an easy target
like star/openoffice. (Yeah, KDE sucketh. And X should be able to figure
out that windows not currently being displayed at all (completely behind
other windows, on another desktop, etc) can be swapped out. But it's just
not designed that way...)
> > Even the new threading work can potentially help X spin off a dedicated
> > high-priority "update the mouse position, and manipulate window borders
> > and z order, and never swap this thread out" thread. (I remember the way
> > OS/2 used to cheat and give extra time slices to anything that got a
> > Presentation Manager window event, so you could literally speed up your
> > program on a loaded system by "scrubbing" the mouse across it repeatedly.
> > The resulting perception was a snappy desktop, whatever the reality was.)
>
> Not really - the application may want the mouse pointer changed, update
> data based on where the mouse is located (see what happens to a rule bar on
> image/word processors). There is also the possibility that multiple
> processes are watching the mouse.
You may notice that in mozilla when your rat moves over a link, the mouse
pointer turns into a hand anywhere up to several seconds later on a
pathologically loaded system. This usually doesn't stop the pointer from
moving if you just want to wander past the link and continue on. "Tooltips"
take two or three seconds to pop up, and this is a GOOD thing...
if the mouse movement stalls, you can't navigate with a nipple mouse or
touchpad (which is all you get on a laptop), 'cause you'll overshoot. Having
the button under the mouse highlight is secondary to being able to get the
mouse over the button.
When the system isn't loaded anymore (went away while a compile finished or a
file downloaded), you get one or two small (1/4 second) stalls as stuff swaps
back in and then life is good. It's when you swap stuff in and then it swaps
back out after 3 seconds of inactivity that it gets to be a real pain
(something the deadline I/O scheduler is supposed to help)...
Maybe the correct thing here is a user space fix, with X throwing certain
event handlers into an mlocked shared library, just so your mouse pointer
always updates smoothly. But I do know a lot of work has gone into making
more intelligent swapping decisions (fundamentally, that's all VM work really
is), and it's certainly a heck of a lot better than the 2.4.6 days where you
had to go get a beverage when it went swap-happy and it could be 30 seconds
between pointer updates.
> Even M$ Windows will lockup when it swaps out the application. The mouse
> might move... but then the entire system hangs (at least under ME).
The amazing number of things windows manages to screw up should not be used
to prevent discussiona about the small number of things they successfully
copied from the macintosh. :)
Rob
-
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:59 EST