|| ||Yasunori Goto <firstname.lastname@example.org>|
|| ||email@example.com, firstname.lastname@example.org|
|| ||[RFC/Patch]Making Removable zone[0/4]|
|| ||Mon, 25 Oct 2004 19:24:59 -0700|
This patch set is to make new zone (Hotremovable) for
memory hotplug to create area which is removed relatively easily.
I made this patch set 2 month ago,
but I thought this patch set has many problem,
so I was worried whether it should be posted for a long time.
However I'm feeling its time become too long.
So, I post this to ask which is better way.
If you have any suggestions, please tell me.
This patches make Hotremovable attribute as orthogonal against
DMA/Normal/Highmem. So, there will be six zones
(DMA/Normal/Highmem/ Removable DMA/ Removable Normal/
However, this orthogonal attribute is cause of problems like
1) Zone Id bits in page->flags must be extended from 2 to 3
to make 6 zones. However, there is not enough space in it.
2) Array size of zonelist for 6 zones might be too big.
(Especially, when there are a lot of numbers of nodes)
3) Index of zonelist array is decided by __GFP_xxx bit. So,
index must be power of 2. But, GFP_Removable can be set with
GFP_HIGHMEM or GFP_DMA. (not power of 2).
4) Some of kernel codes assume that order of Zone's index is
DMA -> Normal -> Highmem.
But removable attribute will break its order.
5) Zonelist order must be also changed.
Which is better zonelist order?
a) Removable Highmem -> Removable Normal -> Removable DMA
-> Highmem -> Normal -> DMA
b) Removable Highmem -> Highmem -> Removable Normal -> Normal
-> Removable DMA -> DMA
If the kind of zone is just 4 types like DMA/Normal/Highmem/Removable
(Not orthogonal), some of these problems become easy.
And I suppose 4) and 5) imply more codes like mem_molicy
must be changed.
But 6 zones code has an advantage for hotplug of kernel memory.
If an component of kernel can become hot-removable,
probably it would like to use "Horemovable DMA" or
So, I also worried which type of removable zone is better.
These patch set is old, but they can be applied against 2.6.9-mm1.
Yasunori Goto <ygoto at us.fujitsu.com>
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to email@example.com. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"firstname.lastname@example.org"> email@example.com </a>