pearing off zone from physical memory layout [0/10]

Hi,

This series of patches remove members from zone, which depends on physical memory layout, zone_start_pfn, spanned_pages, zone_mem_map against 2.6.16-rc1.

By this, zone's meaning will be changed from "a range of memory to be used in a same manner" to "a group of memory to be used in a same manner".

Now, the kernel and memmap became sparse if SPARSEMEM=y, but zone is considered as a range of memory.

memory-hot-add adds memory to HIGHMEM, but a zone is considered as a range. This means memory layout (after hot add) like this is ok, NORMAL | NORMAL | HIGHMEM | HIGHMEM.
but this is insane
NORMAL | HIGHMEM | NORMAL | HIGHMEM. (we can do, but insane)

IMHO, a zone is an unit of allocation/reclaim of same type of pages. I think that a zone should be defined by its usage/purpose not by physical memory layout.

Some codes which wants to walk through all pages in a zone is supported by for_each_page_in_zone() macro.

I tested this on my desktop machine a little, but I know this patch needs more work on some arch (ia64 etc...).

comments ?

-- Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

For us on IA64 a zone describes the memory of a node in a NUMA system. This is due to our IA64 not having memory issues like restricted DMA areas or not directly addressable memory.

That memory is to be used in the same manner. Yes. So in principle this would also work for us. I'd like to have an option though to get rid of all the extra zones if one has a clean memory architecture. We still carry the DMA and HIGHMEM stuff around without purpose.

Would this also mean that one can dynamically add/remove memory to a zone if the memory has to be treated the same way?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Unfortunately, some of ia64 machines has DMA zone (for support 32bit bus < 4G mem). But yes, HIGHMEM is not necessary.

Yes, I think so. When support buddy-system, it can be done by MAX_ORDER size. One of my purpose is to add memory to NORMAL if necessary. (removing looks difficult ?)

Thanks,
-- Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

This looks like pretty good stuff. I especially like that it gets rid of that seqlock that I had to add for memory hotplug. My only concern would be in the increased page_to_pfn() overhead. Any data on that?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

I don't have any data, because I don't have a NUMA environment which needs this. My x86 box is not NUMA and IA64 uses vmem_map, doesn't access zone->zone_mem_map.

Archs which needs test are alpha, arm, m32r, i386, parisc, x86_64. (powerpc doesn't have DISCONTIGMEM config)

To make codes clean before asking test, I posted unify_pfn_to_page patch to lkml. (I'll have to rewrite and repost it..)
After it goes, I'll post renewed patch as request-for-test.

sorry for Bad e-mail subject :(
Thanks,
-- Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>