linux-kernel - Re: [PATCH v2 0/5] rcu,nohz,kvm: use RCU extended quiescent state when running KVM guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54D4D70B.2040300@de.ibm.com>
Date:	Fri, 06 Feb 2015 16:00:27 +0100
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	riel@...hat.com, kvm@...r.kernel.org
CC:	linux-kernel@...r.kernel.org, mtosatti@...hat.com,
	mingo@...nel.orgm, ak@...ux.intel.com, oleg@...hat.com,
	masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
	paulmck@...ux.vnet.ibm.com, lcapitulino@...hat.com,
	pbonzini@...hat.com, linux-s390 <linux-s390@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] rcu,nohz,kvm: use RCU extended quiescent state
 when running KVM guest

Am 05.02.2015 um 21:23 schrieb riel@...hat.com:
> When running a KVM guest on a system with NOHZ_FULL enabled, and the
> KVM guest running with idle=poll mode, we still get wakeups of the
> rcuos/N threads.
> 
> This problem has already been solved for user space by telling the
> RCU subsystem that the CPU is in an extended quiescent state while
> running user space code.
> 
> This patch series extends that code a little bit to make it usable
> to track KVM guest space, too.
> 
> I tested the code by booting a KVM guest with idle=poll, on a system
> with NOHZ_FULL enabled on most CPUs, and a VCPU thread bound to a
> CPU. In a 10 second interval, rcuos/N threads on other CPUs got woken
> up several times, while the rcuos thread on the CPU running the bound
> and alwasy running VCPU thread never got woken up once.
> 
> Thanks to Christian Borntraeger and Paul McKenney for reviewing the
> first version of this patch series, and helping optimize patch 4/5.

I gave it a quick run on s390/kvm and everything still seem to be 
running fine. A also I like the idea of this patch set.

We have seen several cases were the fact that we are in guest context
a full tick for cpu bound guests (10ms on s390) caused significant
latencies for host synchronize-rcu heavy workload - e.g. getting rid
of macvtap devices on guest shutdown, adding hundreds of irq routes
for many guest devices....

s390 has no context tracking infrastructure yet (no nohz_full), but
this series looks like that the current case (nohz_idle) still works.
With this in place, having hohz==full on s390 now even makes more
sense, as KVM hosts with cpu bound guests should have get much quicker
rcu response times when most host CPUs are in an extended quiescant
state.

Christian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/