From: Bob Liu <bob.liu@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Bob Liu <lliubbo@gmail.com>,
keir@xen.org, ian.campbell@citrix.com, andrew.cooper3@citrix.com,
xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [RFC PATCH] xen: free_domheap_pages: delay page scrub to tasklet
Date: Tue, 20 May 2014 16:14:52 +0800 [thread overview]
Message-ID: <537B0EFC.9070401@oracle.com> (raw)
In-Reply-To: <537B1FC70200007800013ECF@mail.emea.novell.com>
On 05/20/2014 03:26 PM, Jan Beulich wrote:
>>>> On 20.05.14 at 09:11, <bob.liu@oracle.com> wrote:
>> On 05/20/2014 02:27 PM, Jan Beulich wrote:
>>> So if you have the system scrub 1Tb at boot (via suitable
>>> dom0_mem=), how long does that take?
>>>
>>
>> I only have a 32G machine, the 1Tb bug was reported by our testing engineer.
>>
>> On 32G machine, if set dom0_mem=2G the scrub time in "(XEN) Scrubbing
>> Free RAM:" is around 12s at boot.
>>
>> The xl destroy time for a 30G guest is always around 15s even decreased
>> the rate of calling hypercall_preempt_check().
>
> Okay, so these numbers at least appear to correlate. And in fact I
> think 3Gb/s (approximated) isn't that unreasonable a number; at
> least it's not orders of magnitude away from theoretical bandwidth.
>
> Which means yes, better dealing with the load resulting from the
> post-guest-death scrubbing would be desirable, but otoh it's also
> not really unexpected for this taking minutes for huge guests. Any
> change here clearly need proper judgment between latency and
> the effect on other guests it has: As said previously, impacting all
> other guests just so that the scrubbing would get done quickly
> doesn't seem right either.
>
Yes, so I have sent out an new version mainly based on your suggestions
with title "[RFC PATCH v2] xen: free_domheap_pages: delay page scrub to
idle loop".
Pages are added to a percpu scrub list in free_domheap_pages(), and the
real scrub work is done in idle_loop(). By this way, no scrub work is
assigned to unrelated cpu which never executes free_domheap_pages().
The trade off is we can't use all cpu resources to do the scrub job in
parallel.
But at least we arrived:
1. Make xl destroy return faster, ~3s for a 30G guest.
2. Do the scrub job in idle_loop() is still faster than in
relinquish_memory(), because E.g there are some atomic instructions in
relinquish_memory() every loop.
Please take a review.
Thanks,
-Bob
prev parent reply other threads:[~2014-05-20 8:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 2:57 [RFC PATCH] xen: free_domheap_pages: delay page scrub to tasklet Bob Liu
2014-05-19 9:59 ` Andrew Cooper
2014-05-19 10:10 ` Konrad Rzeszutek Wilk
2014-05-19 11:34 ` Jan Beulich
2014-05-20 2:14 ` Bob Liu
2014-05-20 6:27 ` Jan Beulich
2014-05-20 7:11 ` Bob Liu
2014-05-20 7:26 ` Jan Beulich
2014-05-20 8:14 ` Bob Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=537B0EFC.9070401@oracle.com \
--to=bob.liu@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=lliubbo@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.