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
