From: Dario Faggioli <dario.faggioli@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, tim@xen.org, jbeulich@suse.com
Subject: Re: [PATCH v3 4/9] mm: Scrub memory from idle loop
Date: Thu, 11 May 2017 12:26:15 +0200 [thread overview]
Message-ID: <1494498375.7393.5.camel@citrix.com> (raw)
In-Reply-To: <1492184258-3277-5-git-send-email-boris.ostrovsky@oracle.com>
[-- Attachment #1.1: Type: text/plain, Size: 3820 bytes --]
On Fri, 2017-04-14 at 11:37 -0400, Boris Ostrovsky wrote:
> Instead of scrubbing pages during guest destruction (from
> free_heap_pages()) do this opportunistically, from the idle loop.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
> Changes in v3:
> * If memory-only nodes exist, select the closest one for scrubbing
> * Don't scrub from idle loop until we reach SYS_STATE_active.
>
> xen/arch/arm/domain.c | 13 ++++--
> xen/arch/x86/domain.c | 3 +-
> xen/common/page_alloc.c | 98
> +++++++++++++++++++++++++++++++++++++++++-----
> xen/include/xen/mm.h | 1 +
> 4 files changed, 98 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 76310ed..38d6331 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -46,13 +46,16 @@ void idle_loop(void)
> if ( cpu_is_offline(smp_processor_id()) )
> stop_cpu();
>
> - local_irq_disable();
> - if ( cpu_is_haltable(smp_processor_id()) )
> + if ( !scrub_free_pages() )
> {
> - dsb(sy);
> - wfi();
> + local_irq_disable();
> + if ( cpu_is_haltable(smp_processor_id()) )
> + {
> + dsb(sy);
> + wfi();
> + }
> + local_irq_enable();
> }
> - local_irq_enable();
>
> do_tasklet();
> do_softirq();
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 90e2b1f..a5f62b5 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -118,7 +118,8 @@ static void idle_loop(void)
> {
> if ( cpu_is_offline(smp_processor_id()) )
> play_dead();
> - (*pm_idle)();
> + if ( !scrub_free_pages() )
> + (*pm_idle)();
> do_tasklet();
>
This means that, if we got here to run a tasklet (as in, if the idle
vCPU has been forced into execution, because there were a vCPU context
tasklet wanting to run), we will (potentially) do some scrubbing first.
Is this on purpose, and, in any case, ideal? vCPU context tasklets are
not terribly common, but I still don't think it is (ideal).
Not sure how to address this, though. What (the variants of) pm_idle()
uses for deciding whether or not to actually go to sleep is
cpu_is_haltable(), which checks per_cpu(tasklet_work_to_do, cpu):
/*
* Used by idle loop to decide whether there is work to do:
* (1) Run softirqs; or (2) Play dead; or (3) Run tasklets.
*/
#define cpu_is_haltable(cpu) \
(!softirq_pending(cpu) && \
cpu_online(cpu) && \
!per_cpu(tasklet_work_to_do, cpu))
Pulling it out/adding a call to it (cpu_is_haltable()) is ugly, and
probably not what we want (e.g., it's always called with IRQs disabled,
while they're on here).
Maybe we can test tasklet_work_to_do, before calling scrub_free_pages()
(also ugly, IMO).
Or, if scrub_free_pages() is, and always will be, called only from
here, within the idle loop, test tasklet_work_to_do inside, similarly
to what it does already for pending softirqs...
Regards,
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)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-05-11 10:26 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
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 [this message]
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=1494498375.7393.5.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.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 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.