linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

             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