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

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

[KAMEZAWA Hiroyuki]

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Christoph Lameter]

On Fri, 3 Feb 2006, KAMEZAWA Hiroyuki wrote:

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

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Kamezawa Hiroyuki]

Christoph Lameter wrote:
> On Fri, 3 Feb 2006, KAMEZAWA Hiroyuki wrote:
> 
>> 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".
> 
> 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.
> 
Unfortunately, some of ia64 machines has DMA zone (for support 32bit bus < 4G mem).
But yes, HIGHMEM is not necessary.

> Would this also mean that one can dynamically add/remove memory to a zone 
> if the memory has to be treated the same way?
> 
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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Dave Hansen]

On Fri, 2006-02-03 at 16:35 +0900, KAMEZAWA Hiroyuki wrote:
> 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".

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[KAMEZAWA Hiroyuki]

Dave Hansen wrote:
> On Fri, 2006-02-03 at 16:35 +0900, KAMEZAWA Hiroyuki wrote:
>> 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".
> 
> 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?
> 

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>