Re: 2.4.8preX VM problems

Andrew Tridgell
2001-08-01T06:14:32Z

Marcelo,

I've narrowed it down some more. If I apply the whole zone patch
except for this bit:

+ /*
+ * If we are doing zone-specific laundering,
+ * avoid touching pages from zones which do
+ * not have a free shortage.
+ */
+ if (zone && !zone_free_shortage(page->zone)) {
+ list_del(page_lru);
+ list_add(page_lru, &inactive_dirty_list);
+ continue;
+ }
+

then the behaviour is much better:

[root@fraud trd]# ~/readfiles /dev/ddisk
202 MB 202.125 MB/sec
394 MB 192.525 MB/sec
580 MB 185.487 MB/sec
755 MB 175.319 MB/sec
804 MB 41.3387 MB/sec
986 MB 182.5 MB/sec
1115 MB 114.862 MB/sec
1297 MB 182.276 MB/sec
1426 MB 128.983 MB/sec
1603 MB 164.939 MB/sec
1686 MB 82.9556 MB/sec
1866 MB 179.861 MB/sec
1930 MB 63.959 MB/sec

Even given that, the performance isn't exactly stunning. The
"dummy_disk" driver doesn't even do a memset or memcpy so it should
really run at the full memory bandwidth of the machine. We are only
getting a fraction of that (it is a dual PIII/800 server). If I get
time I'll try some profiling.

I also notice that the system peaks at a maximum of just under 750M in
the buffer cache. The system has 1.2G of completely unused memory
which I really expected to be consumed by something that is just
reading from a never-ending block device.

For example:

CPU0 states: 0.0% user, 67.1% system, 0.0% nice, 32.3% idle
CPU1 states: 0.0% user, 65.3% system, 0.0% nice, 34.1% idle
Mem: 2059660K av, 842712K used, 1216948K free, 0K shrd, 740816K buff
Swap: 1052216K av, 0K used, 1052216K free 9496K cached

PID USER PRI NI SIZE RSS SHARE LC STAT %CPU %MEM TIME COMMAND
615 root 14 0 452 452 328 1 R 99.9 0.0 3:52 readfiles
5 root 9 0 0 0 0 1 SW 31.3 0.0 1:03 kswapd
6 root 9 0 0 0 0 0 SW 0.5 0.0 0:04 kreclaimd

I know this is a *long* way from a real world benchmark, but I think
it is perhaps indicative of our buffer cache system getting a bit too
complex again :)

Cheers, Tridge