Re: 2.4.8preX VM problems

Marcelo Tosatti
2001-08-01T07:40:53Z

On Tue, 31 Jul 2001, Andrew Tridgell wrote:

> 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.

Thats expected: we cannot allocate buffercache pages on highmem.

> 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 :)

do_page_launder() stops the laundering loop (which frees pages), in case
it freed a buffercache page, as soon as there is no more global free
shortage (in the global scan case), or as soon as there is no more free
shortage for the specific zone we're scanning.

Thats wrong: we should keep laundering pages if there is _any_ zone under
shortage.

Could you please try the patch below ? (against 2.4.8pre3)

--- linux.orig/mm/vmscan.c Wed Aug 1 04:26:36 2001
+++ linux/mm/vmscan.c Wed Aug 1 04:33:22 2001
@@ -593,13 +593,9 @@
* If we're freeing buffer cache pages, stop when
* we've got enough free memory.
*/
- if (freed_page) {
- if (zone) {
- if (!zone_free_shortage(zone))
- break;
- } else if (!free_shortage())
- break;
- }
+ if (freed_page && !total_free_shortage())
+ break;
+
continue;
} else if (page->mapping && !PageDirty(page)) {
/*