linux-kernel - Re: [PATCH] rcu: Only pin GP kthread when full dynticks is actually used

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]

Date:	Fri, 13 Jun 2014 13:49:03 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Josh Triplett <josh@...htriplett.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] rcu: Only pin GP kthread when full dynticks is actually
 used

On Fri, Jun 13, 2014 at 06:21:32PM +0200, Frederic Weisbecker wrote:
> On Fri, Jun 13, 2014 at 09:16:30AM -0700, Paul E. McKenney wrote:
> > > Is it because we have dynticks CPUs staying too long in the kernel without
> > > taking any quiescent states? Are we perhaps missing some rcu_user_enter() or
> > > things?
> > 
> > Sort of the former, but combined with the fact that in-kernel CPUs still
> > need scheduling-clock interrupts for RCU to make progress.  I could
> > move this to RCU's context-switch hook, but that could be very bad for
> > workloads that do lots of context switching.
> 
> Or I can restart the tick if the CPU stays in the kernel for too long without
> a tick. I think that's what we were doing before but we removed that because
> we never implemented it correctly (we sent scheduler IPI that did nothing...)

That would work for me!

Just out of curiosity, what would you use to determine that the CPU
had been in the kernel too long?

							Thanx, Paul

--
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/