From: Yasunori Goto <ygoto@us.fujitsu.com>
To: lhms-devel@lists.sourceforge.net, linux-mm@kvack.org
Subject: [RFC/Patch]Making Removable zone[0/4]
Date: Mon, 25 Oct 2004 19:24:59 -0700 [thread overview]
Message-ID: <20041025160642.690F.YGOTO@us.fujitsu.com> (raw)
Hello.
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/
Removable Highmem).
However, this orthogonal attribute is cause of problems like
followings....
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
"Hotremovable Normal".
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.
Please comment.
Bye.
--
Yasunori Goto <ygoto at us.fujitsu.com>
--
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:"aart@kvack.org"> aart@kvack.org </a>
next reply other threads:[~2004-10-26 2:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 2:24 Yasunori Goto [this message]
2004-10-26 2:34 ` [RFC/Patch]Making Removable zone[1/4] Yasunori Goto
2004-10-26 2:35 ` [RFC/Patch]Making Removable zone[2/4] Yasunori Goto
2004-10-26 2:36 ` [RFC/Patch]Making Removable zone[3/4] Yasunori Goto
2004-10-26 2:38 ` [RFC/Patch]Making Removable zone[4/4] Yasunori Goto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041025160642.690F.YGOTO@us.fujitsu.com \
--to=ygoto@us.fujitsu.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox