On Tue, Dec 17, 2002 at 10:30:31PM -0600, Peter Seebach wrote:
> In message <20021218142059.0ff9798b.ggm@apnic.net>, George Michaelson writes:
> >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.
> 
> FWIW, my system having this problem is a P4 2Ghz with 640MB.  Mozilla
> cannot coexist with, say, cvs update... but that's ridiculous, because
> even if Mozilla is taking 100MB of memory, I should be able to eke out
> an existence with only a couple hundred MB of disk cache.

I just don't buy the "X11 is too big and bloated" argument.  X11 has been
around for a good long time.  While it has gotten bigger and more
resource intensive than when it was running on 68020s, today's
processors and memories are *vastly* more powerful and today's systems
offload much of the heavy graphics work to the accelerated video cards.
Just the video cards of today make the original X11 based workstations
look like two sticks and a rock.

There's an issue here, but its not a couple of applications with 35M
footprints on half-gig-plus RAM systems.  I see similar problems with
audio playback.  When there's some heavy swapping going on, realplayer
will develop popping sounds or drop audio altogether.  Similar things
happen with mplayer playing mp3s.  I've seen this with an dual P2/eap(4)
based card, and a P3/clcs(4) based system.

Without looking at the code, I would guess that certain IDE accesses
lock out the rest of the system for way too long.  The result is cursors
that don't move and audio that skips.  The problem may be limited to UVM
interaction with IDE.  It may be more widespread throughout the
interrupt handling code.  I don't know.

I would also guess that better choices could be made regarding which
pages to swap out.  UVM and UBC are great, but from the ML traffic I've
seen and from personal experience, they are not the end result.  I need
to read the UVM paper before I can be more specific in my comments.

I would suggest that reserving memory for metadata buffers is limiting,
both for applications trying to get memory and servers trying to cache
files.  Keep a small pool of buffers for emergency kernel use, allow
certain critical kernel buffers to be locked down, but let the
"day-to-day" allocations compete with everyone else.

Some of this isn't easy.  It's not supposed to be.  If it were, it would
have been done thirty years ago.

jf
-- 
John Franklin
franklin@elfie.org
ICBM: 35°43'56"N 78°53'27"W