linux-kernel - Re: [PATCH tip/core/rcu 4/7] rcu: Unify boost and kthread priorities

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] [day] [month] [year] [list]

Date:	Fri, 31 Oct 2014 09:57:16 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com,
	Clark Williams <clark.williams@...il.com>
Subject: Re: [PATCH tip/core/rcu 4/7] rcu: Unify boost and kthread priorities

On Fri, Oct 31, 2014 at 05:51:43PM +0100, Peter Zijlstra wrote:
> On Fri, Oct 31, 2014 at 09:42:30AM -0700, Paul E. McKenney wrote:
> 
> > Well, you are supposed to determine the highest RT priority at which
> > your workload might run CPU-bound tasks, and set the boost priority
> > at some level above that.  My model of RCU priority boosting is that
> > it should be used to make inadvertent high-priority infinite loops
> > easier to debug, but others might have different approaches.
> 
> Ah, so DL will never be CPU-bound -- and RR/FIFO _should_ never be, but
> I digress ;-)

;-) ;-) ;-)

> > > We should be able to detect the case where more and work piles on and
> > > the actual running does not appear to catch up, but I'm not sure what to
> > > do about it, seeing how system stability is at risk.
> > 
> > I could imagine having a backup SCHED_FIFO task that handled the
> > case where callbacks were piling up, but synchronizing it with the
> > SCHED_DEADLINE task while avoiding callback misordering could be a bit
> > "interesting".  (Recall that callback misordering messes up rcu_barrier().)
> 
> Ah, so there is talk of 'soft' CBS modes, which instead of hard throttle
> either reclaim 'unused' DL bandwidth, or continue running in lower scheduling
> classes.

OK, something like that might work in this case, at least making the
dubious assumption that I actually understand what you are getting at.  ;-)

You might be amused to hear that one of the solutions in my back pocket
for the potential problem of callbacks piling up in the current RCU
priority boosting scheme is to temporarily increase the priority.  This is
similar to how blimit gets increased if too many callbacks pile up.

Thus far, no need for this back-pocket solution, but I wanted to put it
out there in case it sparks something in the SCHED_DEADLINE approach.

							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/