linux-kernel - Re: Should RCU_BOOST kernels use hrtimers in GP kthread?

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:   Wed, 17 Feb 2021 20:43:59 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
        tglx@...utronix.de
Subject: Re: Should RCU_BOOST kernels use hrtimers in GP kthread?

On 2021-02-17 11:19:07 [-0800], Paul E. McKenney wrote:
> > Ah. One nice thing is that you can move the RCU threads to a house
> > keeping CPU - away from the CPU(s) running the RT tasks. Would this
> > scenario be still affected (if ksoftirqd would be blocked)?
> 
> At this point, I am going to say that it is the sysadm's job to place
> the rcuo kthreads, and if they are placed poorly, life is hard.

Good. Because that is what I suggest :)

> > Oh. One thing I forgot to mention: the timer_list timer is nice in terms
> > of moving forward (the timer did not fire, the condition is true and you
> > move the timeout forward).
> > A hrtimer timer on the other hand needs to be removed, forwarded and
> > added back to the "timer tree". This is considered more expensive
> > especially if the timer does not fire.
> 
> There are some timers that are used to cause a wakeup to happen from
> a clean environment, but maybe these can instead use irq-work.

irq-work has also a "hard" mode because people ended up to throwing
everything in there.

> That it can!  Aravinda Prasad prototyped a mechanism hinting to the
> hypervisor in such cases, but I don't know that this ever saw the light
> of day.

Ah, good to know.

> > My understanding of the need for RCU boosting is to get a task,
> > preempted (by a RT task) within a RCU section, back on the CPU to
> > at least close the RCU section. So it is possible to run RCU callbacks
> > and free memory.
> > The 10 seconds without RCU callbacks shouldn't be bad unless the OOM
> > killer got nervous (and if we had memory allocation failures).
> > Also, running thousands of accumulated callbacks isn't good either.
> 
> Sounds good, thank you!

I hope my understanding was correct. Glad to be if service :)

> 
> 							Thanx, Paul
> 
Sebastian