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:
pgpO6j1bav4JB.pgp
Description: PGP signature
- References:
- Re: x86_64 memory hotplug simulation support?
- From: Yasunori Goto <[email protected]>
- Re: x86_64 memory hotplug simulation support?
- From: Nigel Cunningham <[email protected]>
- Re: x86_64 memory hotplug simulation support?
- From: Yasunori Goto <[email protected]>
- Re: x86_64 memory hotplug simulation support?
- Prev by Date: Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Next by Date: Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Previous by thread: Re: x86_64 memory hotplug simulation support?
- Next by thread: CRAMFS support for 4KB page NAND FLASH
- Index(es):
 |