Re: vm philosophising

From: Bill Davidsen (davidsen@tmr.com)
Date: Mon Jan 21 2002 - 12:55:30 EST


On Thu, 17 Jan 2002, Matthew Johnson wrote:

> How does one test the VM precisley? Sorry for the ignorance on this subject.

Having been active doing just that, I have been triggering my favorite bad
behaviour and trying to evaluate which (if either) makes the system run
better, as defined by both measurements and "feel."

The two problems I have been seeing are (1) load with low to moderate
memory, and (2) sudden i/o bursts freezing the system when doing large
writes (CD image creation).

My test for #1 is simple, I compile the 2.4.16 stock kernel after booting
with mem=64m or mem=128m options. I have a batch of files to hack into
something I can post, and I ran on an Athlon 1400 and dual Celeron 500
system, so I have moderate UP and SMP machines of similar performance when
full memory is used. I compile with:
  make clean; make dep
  make bzImage modules MAKE='make -j7'

I took all these numbers with the intent of posting, but the runs finished
at 0630 this morning and I haven't the time yet. Gut feeling is that
17-rmap-11c works better under small memory, 18pre2aa2 was better when
creating CD images on the Athlon, ran out of time for the SMP.

Neither crashed, hung, or caused the OOM to commit procedural genocide,
which plain 2.4.17 does. the -aa kernel was also tested with my own patch
for intermediate disk loads, I will post when I'm sure it's actually
better by enough to matter. I believe the extra tuning in -aa allows
better large i/o performance if you match bdflush to your load.

Chech large i/o by sync() followed by a fast CD build from wav files, on
fast disk. When the disk light come on hard, grab a window and try to wave
it around, or change X virtual desktops. Chances are that you will get bad
to nil response if you have fast disk and CPU. I get a whole 600MB in
memory before the light comes on :-(

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

- 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 : Wed Jan 23 2002 - 21:00:47 EST