Re: 2.6.18-rc1-mm1 oops on x86_64

[Christoph Lameter <clameter@sgi.com>]

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.