From: Peter Zijlstra <peterz@infradead.org>
To: Avi Kivity <avi@redhat.com>
Cc: "Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
mingo@elte.hu, jeremy@goop.org, mtosatti@redhat.com,
kvm@vger.kernel.org, x86@kernel.org, vatsa@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org, hpa@zytor.com,
paulmck <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v1 3/5] KVM: Add paravirt kvm_flush_tlb_others
Date: Tue, 01 May 2012 18:16:46 +0200 [thread overview]
Message-ID: <1335889006.13683.162.camel@twins> (raw)
In-Reply-To: <4FA002F4.8000508@redhat.com>
On Tue, 2012-05-01 at 18:36 +0300, Avi Kivity wrote:
> > > What bounds the amount of memory waiting to be freed during an rcu grace
> > > period?
> >
> > Most RCU implementations don't have limits, so that could be quite a
> > lot. I think preemptible RCU has a batch limit at which point it tries
> > rather hard to force a grace period, but I'm not sure if even that
> > provides a hard limit.
> >
> > Practically though, I haven't had reports of PPC/Sparc going funny
> > because of this.
>
> It could be considered a DoS if a user is able to free page tables
> faster than rcu is able to recycle them, possibly triggering the oom
> killer (should that force a grace period before firing from the hip?)
One would think that would be a good thing, yes. However I cannot seem
to find anything like that in the current OOM killer. David, Paul, I
seem to have vague recollections of a discussion about RCU vs OOM, what
was the resolution (if anything) and would something like the below make
sense?
---
mm/oom_kill.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 46bf2ed5..244a371 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -607,6 +607,9 @@ int try_set_zonelist_oom(struct zonelist *zonelist, gfp_t gfp_mask)
struct zone *zone;
int ret = 1;
+ synchronize_sched();
+ synchronize_rcu();
+
spin_lock(&zone_scan_lock);
for_each_zone_zonelist(zone, z, zonelist, gfp_zone(gfp_mask)) {
if (zone_is_oom_locked(zone)) {
next prev parent reply other threads:[~2012-05-01 16:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 16:23 [RFC PATCH v1 0/5] KVM paravirt remote flush tlb Nikunj A. Dadhania
2012-04-27 16:23 ` [RFC PATCH v1 1/5] KVM Guest: Add VCPU running/pre-empted state for guest Nikunj A. Dadhania
2012-05-01 1:03 ` Raghavendra K T
2012-05-01 3:25 ` Nikunj A Dadhania
2012-04-27 16:23 ` [RFC PATCH v1 2/5] KVM-HV: " Nikunj A. Dadhania
2012-04-27 16:24 ` [RFC PATCH v1 3/5] KVM: Add paravirt kvm_flush_tlb_others Nikunj A. Dadhania
2012-04-29 12:23 ` Avi Kivity
2012-05-01 3:34 ` Nikunj A Dadhania
2012-05-01 9:39 ` Peter Zijlstra
2012-05-01 10:47 ` Avi Kivity
2012-05-01 10:57 ` Peter Zijlstra
2012-05-01 10:59 ` Peter Zijlstra
2012-05-01 22:49 ` Jeremy Fitzhardinge
2012-05-03 14:09 ` Stefano Stabellini
2012-05-01 12:12 ` Avi Kivity
2012-05-01 14:59 ` Peter Zijlstra
2012-05-01 15:31 ` Avi Kivity
2012-05-01 15:36 ` Peter Zijlstra
2012-05-01 15:39 ` Avi Kivity
2012-05-01 15:42 ` Peter Zijlstra
2012-05-01 15:11 ` Peter Zijlstra
2012-05-01 15:33 ` Avi Kivity
2012-05-01 15:14 ` Peter Zijlstra
2012-05-01 15:36 ` Avi Kivity
2012-05-01 16:16 ` Peter Zijlstra [this message]
2012-05-01 16:43 ` Paul E. McKenney
2012-05-01 16:18 ` Peter Zijlstra
2012-05-01 16:20 ` Peter Zijlstra
2012-05-02 8:51 ` Nikunj A Dadhania
2012-05-02 10:20 ` Peter Zijlstra
2012-05-02 13:53 ` Nikunj A Dadhania
2012-05-04 4:32 ` Nikunj A Dadhania
2012-05-04 11:44 ` Srivatsa Vaddagiri
2012-05-07 3:10 ` Nikunj A Dadhania
2012-04-27 16:26 ` [RFC PATCH v1 4/5] KVM: get kvm_kick_vcpu out for pv_flush Nikunj A. Dadhania
2012-04-27 16:27 ` [RFC PATCH v1 5/5] KVM: Introduce PV kick in flush tlb Nikunj A. Dadhania
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=1335889006.13683.162.camel@twins \
--to=peterz@infradead.org \
--cc=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=vatsa@linux.vnet.ibm.com \
--cc=x86@kernel.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.