Messages in this thread | | | Date | Wed, 17 Feb 2021 20:43:59 +0100 | From | Sebastian Andrzej Siewior <> | 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
| |