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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®