Re: 2.6.18-rc1-mm1 oops on x86_64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux