Message-Id: <200707051931.02594.nigel@nigel.suspend2.net>
Date:	Thu, 5 Jul 2007 19:31:02 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Yasunori Goto <y-goto@...fujitsu.com>
Cc:	nigel@...pend2.net, LKML <linux-kernel@...r.kernel.org>
Subject: Re: x86_64 memory hotplug simulation support?

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.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists