From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: Improving domU restore time Date: Wed, 02 Jun 2010 09:33:22 -0700 Message-ID: <4C0687D2.6050908@goop.org> References: <20100525103557.GC23903@emperor2.itldev.org> <20100531094243.GB3374@emperor2.itldev.org> <4C053C99.6010906@goop.org> <20100602162413.GA7173@emperor2.itldev.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100602162413.GA7173@emperor2.itldev.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Rafal Wojtczuk Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 06/02/2010 09:24 AM, Rafal Wojtczuk wrote: >> Why not just balloon the domain down? >> > I thought it (well, rather the matching balloon up after restore) would cost > quite some CPU time; it used to AFAIR. But nowadays it looks sensible, in 90ms > range. Yes, that is much cleaner, thank you for the hint. > Aside from the cost of the hypercalls to actually give up the pages, ballooning is just the same as memory allocation from the system's perspective. >>> should be no disk reads at all). Is the single threaded nature of xenstored >>> the possible cause for the delays ? >>> >> Have you tried oxenstored? It works well for me, and seems to be a lot >> faster. >> > Do you mean > http://xenbits.xensource.com/ext/xen-ocaml-tools.hg > ? > After some tweaks to Makefiles (-fPIC is required on x86_64 for libs sources) > it compiles, It builds out of the box for me on my x86-64 machine. > but then it bails during startup with > fatal error: exception Failure("ioctl bind_interdomain failed") > This happens under xen-3.4.3; does it require 4.0.0 ? > No, I don't think so, but it does have to be the first xenstore you run after boot. Ah, but Xen 4 probably has oxenstored build and other fixes which aren't in 3.4.3. In particular, I think it has been brought into the main xen-unstable repo, rather than living off to the side. But it is much quicker than the C one, I think primarily because it is entirely memory resident. > Well, it looks like xc_restore should _usually_ call > xc_map_foreign_batch once per pages batch (once per 1024 read pages), which > looks sensible. xc_add_mmu_update also tries to batch requests. There are > 432 occurences of ioctl syscall in the xc_restore strace output; I am not > sure if it is damagingly numerous. > Time for some profiling to see where the time is going then. J