On Sat, Jan 04, 2020 at 04:21:08PM -0500, Joel Fernandes wrote: > On Fri, Jan 03, 2020 at 06:31:33PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 03, 2020 at 08:56:17PM -0500, Joel Fernandes wrote: > > > On Wed, Dec 25, 2019 at 05:05:32PM -0800, Paul E. McKenney wrote: [ . . . ] > > > > > How about doing this kind of call_rcu() to synchronize_rcu() > > > > > transition automatically if the context allows it? I.e. Detect the > > > > > context and if sleeping is allowed, then wait for the grace period > > > > > synchronously in call_rcu(). Not sure about deadlocks and the like > > > > > from this kind of waiting and have to think more. > > > > > > > > This gets rather strange in a production PREEMPT=n build, so not a > > > > fan, actually. And in real-time systems, I pretty much have to splat > > > > anyway if I slow down call_rcu() by that much. > > > > > > > > So the preference is instead detecting such misconfiguration and issuing > > > > appropriate diagnostics. And making RCU more able to keep up when not > > > > grossly misconfigured, hence the kfree_rcu() memory footprint being > > > > fed into core RCU. > > > > > > Ok. Is it not Ok to simply assume that a large number of callbacks queued > > > along with observing high memory pressure, means RCU should be more > > > aggressive anyway since whatever memory can be freed by invoking callbacks > > > should be helpful anyway? Or were you thinking making RCU aggressive when > > > there's a lot of memory pressure is not worth it, without knowing that RCU is > > > the cause for it? > > > > I used to have a memory-pressure switch for RCU, but the OOM guys hated > > it. But given a reliable "running short of memory" indicator, I would > > be quite happy to use it. After all, even if RCU is not at fault, it > > might still be helpful for it to pull its memory-footprint horns in a bit. > > With recent advances in PSI, I am wondering if those pressure signals (for > memory) can be leveraged to pull the memory-footprint horns. I can look more > into this, I am also looking into PSI for other work things. > > One thing I am wondering though is, say we get a reliable signal -- what > could RCU do? Were you thinking of having the FQS loop set the usual > emergency flags and hope the "RCU-idle" CPUs enter quiescent states, along > with additional signalling for rcu_read_unlock_special()? Will think more > about it.. I am thinking in terms of it reacting to memory pressure in the same way that it currently does when it finds a CPU with more RCU callbacks than it likes. ;-) > As far as testing goes, I was thinking of initially running rcuperf on a > system with less memory and never entering OOM as a "test has passed" > indication. Agreed. I would look at memory-pressure actions as an additional level of memory-footprint guardrail, and I strongly encourage you to set up your testing and deployment so as to allow production use at least one guardrail that normal testing does not slam into. (Yes, there also needs to be focused testing of the last guardrail, but that should be separate, probably an rcutorture option where a reader keeps spinning until memory pressure kicks in.) > > > > > BTW, I have 2 interns working on RCU (Amol and Madupharna also on > > > > > CC). > > > > > They were selected among several others as a part of the > > > > > LinuxFoundation mentorship program. They are familiar with RCU. I have > > > > > asked them to look at some RCU-list work and RCU sparse work. However, > > > > > I can also have them look into a few other things as time permits and > > > > > depending on what interests them. > > > > > > > > Dog paddling before cliff diving, please! ;-) > > > > > > Sure. They are working on relatively simpler things for their internship but > > > I just put these ideas out there with them on CC so they can pick something > > > else as well if they have time and interest ;-) > > > > I considered pointing them at KCSAN reports, but about 5% of them require > > global knowledge. And it is never clear up front which are the 5%. And > > that 5% of "real bugs" is most of the motivation for things like KCSAN. > > Interesting. > > > > > > Thanks, Merry Christmas! > > > > > > > > And to you and yours as well! > > > > > > Hope you had a good holiday season! > > > > It did! First holiday season in quite a few years featuring all > > three kids, though not all at once. Might be awhile until the next > > time that happens. Something about them being about 30 years old and > > widely dispersed. ;-) > > Oh nice, happy to hear that and hope this year end brings the same. > > > As the little one becomes more aware, your holiday seasons should become > > quite fun. Don't miss out! ;-) > > Looking forward to it and will do ;) ;-) ;-) ;-) Thanx, Paul
