[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] how to move the memory of a domain from one NUMAnode to another?



hello,Dario,


linux provides the function move_pages ,which can move individual pages of a process to another node,as follows:

long move_pages(int pid, unsigned long count, void **pages,
    const int *nodes, int *status, int flags);

Therefore,if xen can provide the similar approach,then we recognize the hot memory pages,and preferentially migrate the hot memory pages.Then the efficiecy of VM's migration will be very high.

And how to improve about the new version of memory migration?  

 

======= 2013-08-07 19:15:21 From your letter:=======

>On mer, 2013-08-07 at 18:55 +0800, butine@xxxxxxxxxx wrote:
>> hello,Dario,
>>
>Hi,
>
>> I have been studying in your patch about "memory migration",
>>
>Oh, you are? Cool... What do you think about'em? :-)
>
>I'm working on a new version of that series from quite a while now, but
>I keep being sidetracked by various things. Anyway, as of now, It
>shouldn't take much longer to be able to repost something...
>
>> how to recognize the hot memory,
>>
>And do you have any idea of that?
>
>The two options I can think of are performance counters (but they're
>coarse grained, they're not available on all archs, etc.) and 'hinting
>page faults'. That is something Linux does, i.e., it periodically
>removes the _PAGE_PRESENT bit from all the pages and, when the page
>fault occurs, it make a note of where the page is and from where it is
>being accessed (and at that point you can even count how many times,
>etc.).
>
>That being said, the point here is, would that be worth? I mean, for
>Linux is not a big deal to migrate just one (or a bunch of) page(s) at a
>time, for us here, it indeed is quite a big deal (PV guests!!). So I
>honestly don't think we can take the same approach and hence, while it
>would be useful to have some info about the above, I'm not sure it's
>terribly important.
>
>Thoughts?
>
>> and how to gurantee no downtime.
>>
>And again, did you reach any conclusion on this? :-)
>
>I do not think that, for PV guest, zero downtime is almost impossible.
>Right now I'm doing a very quick suspend-resume alike cycle. We can (in
>future) try to turn it into something even more lightweight (some kind
>of quiescence state), but you don't change the PTEs under the feet of a
>running domain! :-O
>
>> At the same time,In the migration process,the P2M need to be locked?
>>
>Well, right now I'm suspending the domain, so I really think it does
>not.
>
>Dario
>
>--
><<This happens because I choose it to happen!>> (Raistlin Majere)
>-----------------------------------------------------------------
>Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxx
>http://lists.xen.org/xen-devel
>

= = = = = = = = = = = = = = = = = = = =
   

Thanks,

Regards,

Butine Huang

2013-08-08

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.