From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, sstabellini@kernel.org, wei.liu2@citrix.com,
George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v3 4/9] mm: Scrub memory from idle loop
Date: Fri, 5 May 2017 09:42:32 -0400 [thread overview]
Message-ID: <ddb8ee53-8697-c89f-4c2f-5aaa544a49b8@oracle.com> (raw)
In-Reply-To: <590C6E6602000078001571F3@prv-mh.provo.novell.com>
>>>> +bool scrub_free_pages(void)
>>>> {
>>>> struct page_info *pg;
>>>> unsigned int zone, order;
>>>> unsigned long i;
>>>> + unsigned int cpu = smp_processor_id();
>>>> + bool preempt = false;
>>>> + nodeid_t node;
>>>>
>>>> - ASSERT(spin_is_locked(&heap_lock));
>>>> + /*
>>>> + * Don't scrub while dom0 is being constructed since we may
>>>> + * fail trying to call map_domain_page() from scrub_one_page().
>>>> + */
>>>> + if ( system_state < SYS_STATE_active )
>>>> + return false;
>>> I assume that's because of the mapcache vcpu override? That's x86
>>> specific though, so the restriction here ought to be arch specific.
>>> Even better would be to find a way to avoid this restriction
>>> altogether, as on bigger systems only one CPU is actually busy
>>> while building Dom0, so all others could be happily scrubbing. Could
>>> that override become a per-CPU one perhaps?
>> Is it worth doing though? What you are saying below is exactly why I
>> simply return here --- there were very few dirty pages.
> Well, in that case the comment should cover this second reason as
> well, at the very least.
>
>> This may change
>> if we decide to use idle-loop scrubbing for boot scrubbing as well (as
>> Andrew suggested earlier) but there is little reason to do it now IMO.
> Why not? In fact I had meant to ask why your series doesn't
> include that?
This felt to me like a separate feature.
>
>>> Otoh there's not much to scrub yet until Dom0 had all its memory
>>> allocated, and we know which pages truly remain free (wanting
>>> what is currently the boot time scrubbing done on them). But that
>>> point in time may still be earlier than when we switch to
>>> SYS_STATE_active.
> IOW I think boot scrubbing could be kicked off as soon as Dom0
> had the bulk of its memory allocated.
Since we only are trying to avoid mapcache vcpu override can't we just
scrub whenever override is NULL (per-cpu or not)?
>
>>>> @@ -1065,16 +1131,29 @@ static void scrub_free_pages(unsigned int node)
>>>> pg[i].count_info &= ~PGC_need_scrub;
>>>> node_need_scrub[node]--;
>>>> }
>>>> + if ( softirq_pending(cpu) )
>>>> + {
>>>> + preempt = true;
>>>> + break;
>>>> + }
>>> Isn't this a little too eager, especially if you didn't have to scrub
>>> the page on this iteration?
>> What would be a good place then? Count how actually scrubbed pages and
>> check for pending interrupts every so many?
> Yes.
>
>> Even if we don't scrub at all walking whole heap can take a while.
> Correct - you can't skip this check altogether even if no page
> requires actual scrubbing.
But then how will counting help --- we want to periodically check even
when count is zero? Once per zone? That still may be too infrequent
since we may have, for example, one dirty page per order and so we are
scanning whole order but bumping the count by only one.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-05-05 13:42 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-14 15:37 [PATCH v3 0/9] Memory scrubbing from idle loop Boris Ostrovsky
2017-04-14 15:37 ` [PATCH v3 1/9] mm: Separate free page chunk merging into its own routine Boris Ostrovsky
2017-05-04 9:45 ` Jan Beulich
2017-04-14 15:37 ` [PATCH v3 2/9] mm: Place unscrubbed pages at the end of pagelist Boris Ostrovsky
2017-05-04 10:17 ` Jan Beulich
2017-05-04 14:53 ` Boris Ostrovsky
2017-05-04 15:00 ` Jan Beulich
2017-05-08 16:41 ` George Dunlap
2017-05-08 16:59 ` Boris Ostrovsky
2017-04-14 15:37 ` [PATCH v3 3/9] mm: Scrub pages in alloc_heap_pages() if needed Boris Ostrovsky
2017-05-04 14:44 ` Jan Beulich
2017-05-04 15:04 ` Boris Ostrovsky
2017-05-04 15:36 ` Jan Beulich
2017-04-14 15:37 ` [PATCH v3 4/9] mm: Scrub memory from idle loop Boris Ostrovsky
2017-05-04 15:31 ` Jan Beulich
2017-05-04 17:09 ` Boris Ostrovsky
2017-05-05 10:21 ` Jan Beulich
2017-05-05 13:42 ` Boris Ostrovsky [this message]
2017-05-05 14:10 ` Jan Beulich
2017-05-05 14:14 ` Jan Beulich
2017-05-05 14:27 ` Boris Ostrovsky
2017-05-05 14:51 ` Jan Beulich
2017-05-05 15:23 ` Boris Ostrovsky
2017-05-05 16:05 ` Jan Beulich
2017-05-05 16:49 ` Boris Ostrovsky
2017-05-08 7:14 ` Jan Beulich
2017-05-11 10:26 ` Dario Faggioli
2017-05-11 14:19 ` Boris Ostrovsky
2017-05-11 15:48 ` Dario Faggioli
2017-05-11 17:05 ` Boris Ostrovsky
2017-05-12 8:17 ` Dario Faggioli
2017-05-12 14:42 ` Boris Ostrovsky
2017-04-14 15:37 ` [PATCH v3 5/9] mm: Do not discard already-scrubbed pages if softirqs are pending Boris Ostrovsky
2017-05-04 15:43 ` Jan Beulich
2017-05-04 17:18 ` Boris Ostrovsky
2017-05-05 10:27 ` Jan Beulich
2017-05-05 13:51 ` Boris Ostrovsky
2017-05-05 14:13 ` Jan Beulich
2017-04-14 15:37 ` [PATCH v3 6/9] spinlock: Introduce spin_lock_cb() Boris Ostrovsky
2017-04-14 15:37 ` [PATCH v3 7/9] mm: Keep pages available for allocation while scrubbing Boris Ostrovsky
2017-05-04 16:03 ` Jan Beulich
2017-05-04 17:26 ` Boris Ostrovsky
2017-05-05 10:28 ` Jan Beulich
2017-04-14 15:37 ` [PATCH v3 8/9] mm: Print number of unscrubbed pages in 'H' debug handler Boris Ostrovsky
2017-04-14 15:37 ` [PATCH v3 9/9] mm: Make sure pages are scrubbed Boris Ostrovsky
2017-05-05 15:05 ` Jan Beulich
2017-05-08 15:48 ` Konrad Rzeszutek Wilk
2017-05-08 16:23 ` Boris Ostrovsky
2017-05-02 14:46 ` [PATCH v3 0/9] Memory scrubbing from idle loop Boris Ostrovsky
2017-05-02 14:58 ` Jan Beulich
2017-05-02 15:07 ` Boris Ostrovsky
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=ddb8ee53-8697-c89f-4c2f-5aaa544a49b8@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).