From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: nigel@suspend2.net, LKML <linux-kernel@vger.kernel.org>
Subject: Re: x86_64 memory hotplug simulation support?
Date: Thu, 5 Jul 2007 19:31:02 +1000 [thread overview]
Message-ID: <200707051931.02594.nigel@nigel.suspend2.net> (raw)
In-Reply-To: <20070705161700.279A.Y-GOTO@jp.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]
Hi.
On Thursday 05 July 2007 18:52:13 Yasunori Goto wrote:
> > Thanks for your reply. Please, just call me Nigel :).
>
> Haha. Okay. Nigel.
> (Though, San is useful for even friendly/frank situation in Japanese :) )
Ah, ok. Sort of like the Aussies among whom I'm living say "Mate", I guess -
in that regard at least.
> > I saw a patch that Dave
> > Hansen had posted, back around the time of 2.6.11 iirc. It was for x86,
and
> > (so far as I understand) allowed a person who doesn't really have
> > hotpluggable memory to make their computer pretend that it does.
> >
> > Just in case I'm not being clear enough, let me get more concrete. I have
had
> > some code for a while that uses bitmaps to simulate page flags, without
> > needing to take up those precious bits in page->flags. I've begun to add
> > support for memory hotplugging, in the hope that I can make it general
enough
> > that it will be useful for more than just suspend2. To do that, I'd like
to
> > be able to test the memory hotplugging paths, without needing to actually
> > have hotpluggable memory. I do have an x86 desktop I could work on, but
would
> > prefer to do it on my x86_64 laptop if I can.
>
> Current memory hot-add code expects special hardware which allows
> memory hot-unplug physically. Yes, these is no way to use it on
> normal PC without emulation. And I don't have emulation code for
> x86-64. Usually, I'm using ia64 box for test it.
>
> These are 2 ideas to use memory hotplug with normal x86-64 box.
>
> - Make emulation code for x86-64.
> To add memory, some of memory have to be ignored at boot time.
> And add memory after boot up.
> This way may need fake BIOS information. And if memory is added once,
> reboot is necessary for next hot-add test.
Mmm. I can do it in a vm; that will make it less painful.
> - Bootup normaly. Unplug some memory at first, then hot-add them
> later. You can try hot-plug code many times after bootup.
>
> Unplug code must is not merged yet. Followings are the newest one.
> http://marc.info/?l=linux-mm&m=118180415304117&w=2
> But the 6th patch of them is only for ia64.
> http://marc.info/?l=linux-mm&m=118180483715610&w=2
> So, same role patch for x86-64 is still necessary.
Ah. I'd forgotten about the existence of the -mm list. I'll take a look when I
get some time to do more of this.
> In addition, some of route of hot-add code can't be tested.
> Because, current hot-add has 2 phase.
> 1. Physically hot-add.
> - Accept notification from firmware.
> - Make sysfs file for new memory.
> - register SPARSEMEM and allocate memmap/pgdat/zone.
> 2. logically online
> - free each pages of new memory to use them.
> - rebuild zonelist.
>
> But, unplug code just do logical offline. physicall hot-unplug
> must be necessary for test phase 1.
>
>
> Hmm. I don't know what is necessary for suspend2.
> But, some works looks still necessary for each way.
I think I could get away with just doing the logical online part. It's mainly
the adding pages to zones that I'm interested in - I'd have to trigger the
expansion (and shrinking) of already allocated bitmaps.
Thanks very much for your help so far!
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2007-07-05 9:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-05 4:30 x86_64 memory hotplug simulation support? Nigel Cunningham
2007-07-05 6:20 ` Yasunori Goto
2007-07-05 6:44 ` Nigel Cunningham
2007-07-05 8:52 ` Yasunori Goto
2007-07-05 9:31 ` Nigel Cunningham [this message]
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=200707051931.02594.nigel@nigel.suspend2.net \
--to=nigel@nigel.suspend2.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nigel@suspend2.net \
--cc=y-goto@jp.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.