[[ please honor my reply-to:, at least if you're going to reply to the
list, so that I don't get duplicates -- and do feel free to set your own
reply-to: similarly! ]]

[ On Wednesday, December 18, 2002 at 14:20:59 (+1000), George Michaelson wrote: ]
> Subject: Re: UVM/other problems for desktop users in current?
>
> I'm running what a normal desktop user self-supporting can expect to have to
> run. If the mix is 'bad' then its worth noting the interactive response on
> other BSD variants (FreeBSD) isn't this bad, and on Linux is impercepable by
> comparison, *for the same job mix*

You can't expect the default out-of-the-box kernel to be tuned ideally
for all possible job mixes.  NetBSD seems to work better, "out of the
box", as a plain multi-user server, not as a "do it all wonder
workstation".  Maybe those other systems have been tuned to give the GUI
a bigger share of the resources pie.

> I realize this is subjective measures stuff, the thing is, its noticably
> differently worse on this NetBSD. Which is a shame, because in so many other
> ways its a better, more runnable release family.

Still, really, what do you expect when you go about asking your CPU do
run a whole bunch of very large applications, all which must display
their updates through another large application, all the while you're
asking it to work as hard it can at running some compiles and doing some
I/O intensive wandering about on large portions of your filesystem?

Something _must_ suffer when you punish your machine that way.  On
NetBSD it's the Xserver, at least that's what happens "out of the box".

> Right. So in not running 'new' kernels, is it possible that we're on the
> 'older is better' track here, the difference between -stable and -current and

No, absolutely not.  My point was that I'm running a kernel that uses
pretty much the default VM tuning parameters (and I haven't changed them
in the code).  If you are running a newer kernel then you have a lot
more knobs to twist than I do.

> So, from the general "big file I/O makes it slow" I'm  honing in on "X is
> really not good in the jobmix here". -Is this maybe something fixable in X, or
> in the way I run X? I self-compiled from /usr/xsrc.

There's really nothing you can do to fix X.  The Xserver is not meant to
be run on a compute server.  The network is the computer!  ;-)

I don't think Xserver should ever be run on the same server system where
anyone is trying to do CPU and I/O intensive work -- the Xserver should
only be run on a workstation that's more tuned to fast display updates
(and one workstation per user!), eg. even a dedicated X-terminal.

A workstation should not be expected to do big I/O and CPU intensive
things like CVS and "make build" and whatnot -- that's a server's job.
A workstation is not a compute server and a workstation is not a file
server.  :-)

You could try tuning your system to give the Xserver process more RAM
and more scheduler priority, and you could lock all it's pages in core
so that it never has to wait for paging, but that'll probably hurt the
throughput of your non-GUI jobs.

As soon as you get accustomed to running your GUI on a workstation and
not on your server(s) then you'll come to appreciate what I said about
never being happy with any system where the Xserver is run on a
multi-user multitasking server.

Sure you can get away with running Xserver and one big application at a
time like Mozilla or what have you on a workstation, but that's because
you're essentially doing primarily GUI stuff.  However once you start
compiling and running I/O intensive stuff like CVS then you're doing
more what's done on a multi-user general-purpose server.  Those two
kinds of application just do not mix well on a single CPU system -- you
can't expect to get good compiler throughput and at the same time have
sub-second GUI response, especially when you context switch through a
half dozen big GUI applications all at once too!

In fact you should probably be happy that your workstation can context
switch fast enough to handle the mouse and the Xserver and one big GUI
application like a mozilla process all at once.  Try that on a SPARC-2
or something older, and be prepared for it to crawl like cold molasses!  ;-)

A GUI of any kind takes a lot of resources, and a different mix of
resources, and a very different set of acceptable response times, than
your average old-fashioned unix job mix.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>