On Thu, Aug 29, 2019 at 11:13:25AM -0400, Joel Fernandes wrote: > On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote: > > On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote: > > [snip] > > > > > > > This change is not fixing a bug, so there is no need for an emergency fix, > > > > > > > and thus no point in additional churn. I understand that it is a bit > > > > > > > annoying to code and test something and have your friendly maintainer say > > > > > > > "sorry, wrong rocks", and the reason that I understand this is that I do > > > > > > > that to myself rather often. > > > > > > > > > > > > The motivation for me for this change is to avoid future bugs such as with > > > > > > the following patch where "== 2" did not take the force write of > > > > > > DYNTICK_IRQ_NONIDLE into account: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=13c4b07593977d9288e5d0c21c89d9ba27e2ea1f > > > > > > > > > > Yes, the current code does need some simplification. > > > > > > > > > > > I still don't see it as pointless churn, it is also a maintenance cost in its > > > > > > current form and the simplification is worth it IMHO both from a readability, > > > > > > and maintenance stand point. > > > > > > > > > > > > I still don't see what's technically wrong with the patch. I could perhaps > > > > > > add the above "== 2" point in the patch? > > > > > > > > > > I don't know of a crash or splat your patch would cause, if that is > > > > > your question. But that is also true of the current code, so the point > > > > > is simplification, not bug fixing. And from what I can see, there is an > > > > > opportunity to simplify quite a bit further. And with something like > > > > > RCU, further simplification is worth -serious- consideration. > > > > > > > > > > > We could also discuss f2f at LPC to see if we can agree about it? > > > > > > > > > > That might make a lot of sense. > > > > > > > > Sure. I am up for a further redesign / simplification. I will think more > > > > about your suggestions and can also further discuss at LPC. > > > > > > One question that might (or might not) help: Given the compound counter, > > > where the low-order hex digit indicates whether the corresponding CPU > > > is running in a non-idle kernel task and the rest of the hex digits > > > indicate the NMI-style nesting counter shifted up by four bits, what > > > could rcu_is_cpu_rrupt_from_idle() be reduced to? > > > > > > > And this patch is on LKML archives and is not going anywhere so there's no > > > > rush I guess ;-) > > > > > > True enough! ;-) > > > > Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see anyone > > using it. And also remove the bottom most bit of dynticks? > > > > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle > > CPUs are the moment? > > > > All of this was introduced in: > > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter") > > > Paul, also what what happens in the following scenario: > > CPU0 CPU1 > > A syscall causes rcu_eqs_exit() > rcu_read_lock(); > ---> FQS loop waiting on > dyntick_snap > usermode-upcall entry -->causes rcu_eqs_enter(); > > usermode-upcall exit -->causes rcu_eqs_exit(); > > ---> FQS loop sees > dyntick snap > increment and > declares CPU0 is > in a QS state > before the > rcu_read_unlock! > > rcu_read_unlock(); > --- > > Does the context tracking not call rcu_user_enter() in this case, or did I > really miss something? Holding rcu_read_lock() across usermode execution (in this case, the usermode upcall) is a bad idea. Why is CPU 0 doing that? Thanx, Paul
