Subject: Re: UVM/other problems for desktop users in current?
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 12/17/2002 23:01:29
On Wed, 18 Dec 2002, Greg A. Woods wrote:
# 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?
850MHz Athlon, 640MB RAM, NetBSD 1.6K (current as of today).
No problems running cvs update -d -P from /usr/src, followed by
a compile of /usr/src, all the while running X and, in fact, xmms.
No music skips, and the build looks like a sun3 running 'make -n'. Also
runs as a file server, though *very* lightly loaded in that department.
Any other explanations? I would suspect that the 256MB RAM has a LOT
to do with this one.
[on the downside, I can't run xMAME during a build with any degree of
smoothitude, and <sarcasm> Gee, Doesn't THAT Just Suck? </sarcasm>.]
# 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.
See above. I flout your example, sirrah! Other people log in here,
# 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. :-)
Heh. "It is if you have a server-class machine acting like a workstation."
Oh, wait, I'm sorry ...
<sarcasm target="purist" intensity="high">
...but all my disks are IDE, so it can't be a server-class machine.
[sorry, is that my outside keyboard...?]
# 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.
Well, SOMEthing is going amiss there that's not happening here
with me. Running softdeps (but not async).
# 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!
Poppycock. What sort of benchmarks would you like for this?
# 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! ;-)
Well, on a SPARCs* 2, sure! X by itself will crawl like cold molasses
on a frozen water pipe. Did that for a while.
This guy's running on a P4 2GHz with as much memory as I do. There
is something else wrong which cannot be explained away by load
# 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.
Now, that I cannot refute. But I could make the same statement pertinent
to a high-availability heavily-used DB server...
NetBSD: Rock solid!