Re: 2.6.18-rc1-mm1 oops on x86_64

Christoph Lameter
2006-07-10T16:21:14Z

On Sun, 9 Jul 2006, Andrew Morton wrote:

> I dunno, Christoph. I think those patches are going to significantly
> increase the number of works-with-my-config, doesnt-with-yours scenarios.
>
> We're going to hurt ourselves if we do this.

On the other hand we also clean up a lot of strange uses of HIGHMEM. The
more we increase common memory the more we will go to 64 bit
configurationa and at that point we want HIGHMEM to have the least impact
possible.

Hmm... Actually we could leave __GFP_HIGHMEM at it prior value since
GFP_ZONEMASK masks it out anyways. Need to test this though. This may
also make some of the __GFP_DMA32 ifdefs unnecessary.

The advantages of zone reduction are:

1. It shortens traversal times of zones lists and significantly reduces
the amounts of cachelines touched (all the for_each_zone constructs).
See __drain_pages, nr_free_pages, show_free_areas, multiple uses in
swap prefetch, shrink_all_zones, shrink_all_memory,
refresh_cpu_vm_stats.

2. It reduces the number of allocations for pagesets significantly. In an
extreme case (1024p 1024 nodes) we currently have 4*1024*4*1024 = 16
mio allocations of pagesets. The reduction brings that down to
2*1024*2*1024 = 4 mio. The number of pagesets grows by the square.

3. The macro changes allow lots of tests to be performed at compile time
rather than at run time.

4. The changes in mmzone.h allow easy additions/removal of zones should
this become necessary in the future.

5. Clean up the output from /proc/meminfo /proc/vmstat
/sys/devices/system/node/nodeX/meminfo for the !CONFIG_HIGHMEM case.

6. Shrink zones struct through removal of useless counters and shrink
pgdat structure by reducing the size of node_zonelists.

7. The reduces zonelists significantly reduce the work to build
the zonelists at startup time.