From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 6 of 8 [RFC]] libxc: introduce xc_domain_move_memory Date: Tue, 9 Apr 2013 10:51:20 +0200 Message-ID: <1365497480.17022.81.camel@Abyss> References: <5163A5E4.6030608@ts.fujitsu.com> <1365490591.17022.14.camel@Abyss> <5163CDA2.7030206@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0823470494245644636==" Return-path: In-Reply-To: <5163CDA2.7030206@ts.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross Cc: Dan Magenheimer , Ian Campbell , George Dunlap , Andrew Cooper , "Tim (Xen.org)" , Olaf Hering , xen-devel , David Vrabel , Keir Fraser , Andres Lagar-Cavilla , Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org --===============0823470494245644636== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-METs4H0KNov2ZCxXND8W" --=-METs4H0KNov2ZCxXND8W Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-04-09 at 09:13 +0100, Juergen Gross wrote: > What about the following approach: >=20 In general, I like it... More details below. > - do the migration in chunks (like 1GB, may be configurable) > Yes, provided these chunks are big enough, I think the overhead of is acceptable. > - don't move pages which are already on one of the target nodes > Yep, that is definitely sane, and was already on my TODO list (although, you're right, I forgot to mention it in the cover or in the various changelogs). It's not there yet because I'm missing a way of knowing on what node a page is, but I'm already working of putting it together. Anyway, I agree on this too, and thanks for pointing that out. :-) > - try to allocate memory on the target node while the domain is still run= ning. > If this fails, there is no need to move that chunk. Depending on the p= age > size requirements (huge pages) decide whether the move is aborted or d= one > partially. > - in case of successful allocation suspend the domain, do the copy and up= date > page tables for the copied pages, then resume the domain > This is also fine, the only issue being that I'd probably need to fiddle with the domain max_mem, and stuff like that, wouldn't I? I'm saying this because, when testing the few that I sent already, I run right into this when I was trying to do it in the allocate-copy-deallocate order (of course, depending on how big a chunk is, but this is going to be much less than 1GB!). Do you see what I mean? Do you think it would be nice to increase the domain's "memory allowance" (temporarily, of course) for this to be possible? > - free the memory chunk on the old node(s) > - repeat until either no memory obtained or move is finished >=20 > This will have higher overhead, but the domain will be suspended for only > short periods of time. The memory requirements don't matter, as the addit= ional > memory will be allocated only for a short period of time.=20 > Yep, this all makes sense, with the only nit being the max_mem issue above. Thanks again and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-METs4H0KNov2ZCxXND8W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iEYEABECAAYFAlFj1ogACgkQk4XaBE3IOsT+qACff46yqy6E5NKO32zyhhozKQ8I CDgAn2QosiNSTl1chc4LGGiCNbtTSrL7 =fYC6 -----END PGP SIGNATURE----- --=-METs4H0KNov2ZCxXND8W-- --===============0823470494245644636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0823470494245644636==--