x86_64 memory hotplug simulation support?

x86_64 memory hotplug simulation support?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

Hi all.

I'm wondering whether anyone has patches lying around that might be useful for 
simulating memory hotplug on x86_64. Goggling has revealed some old x86 
patches, but that's all.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: x86_64 memory hotplug simulation support?

[Yasunori Goto]

Hello. Nigel-san.

> I'm wondering whether anyone has patches lying around that might be useful for 
> simulating memory hotplug on x86_64. Goggling has revealed some old x86 
> patches, but that's all.

I'm not sure what "simulation" means.
Could you tell me how/what do you expect memory hotplug
simulation exactly?

Memory hot-add code is included in kernel. And, remove(unplug) code
has developed (and hopefully, it will be merged to -mm after
some cleanups, I think.)

I would like to make sure what is necessary.

Thanks.

-- 
Yasunori Goto 

Re: x86_64 memory hotplug simulation support?

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Hi.

On Thursday 05 July 2007 16:20:18 Yasunori Goto wrote:
> Hello. Nigel-san.
> 
> > I'm wondering whether anyone has patches lying around that might be useful 
for 
> > simulating memory hotplug on x86_64. Goggling has revealed some old x86 
> > patches, but that's all.
> 
> I'm not sure what "simulation" means.
> Could you tell me how/what do you expect memory hotplug
> simulation exactly?
> 
> Memory hot-add code is included in kernel. And, remove(unplug) code
> has developed (and hopefully, it will be merged to -mm after
> some cleanups, I think.)
> 
> I would like to make sure what is necessary.

Thanks for your reply. Please, just call me Nigel :). 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.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: x86_64 memory hotplug simulation support?

[Yasunori Goto]

> Thanks for your reply. Please, just call me Nigel :).

Haha. Okay. Nigel.
(Though, San is useful for even friendly/frank situation in Japanese :) )

> 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.

- 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.

  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. 

Thanks.

-- 
Yasunori Goto 

Re: x86_64 memory hotplug simulation support?

[Nigel Cunningham]

[-- 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 --]