Re: [Ksummit-discuss] Nominations for Kernel Summit

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, May 09, 2014 at 12:46:04PM -0400, Paul Gortmaker wrote:
> On 14-05-07 08:16 PM, Paul E. McKenney wrote:
> > On Fri, May 02, 2014 at 09:56:59AM -0700, Josh Triplett wrote:
> >> I'd like to nominate the following people:
> >>
> >> - Tom Zanussi <tom.zanussi@linux.intel.com> - doing extensive work on
> >>   shrinking the kernel and embedded userspace to fit in shockingly tiny
> >>   spaces.
> >> - Julia Lawall <julia.lawall@lip6.fr> - maintainer of cocinelle, the
> >>   semantic patch tool, which has collectively saved an incredible amount
> >>   of kernel maintainer time and effort.
> >> - Andi Kleen <ak@linux.intel.com> - working on LTO and many other kernel
> >>   projects.
> >>
> >> I'd also like to nominate myself; in addition to the kernel tinification
> >> topic I've already proposed, I plan to coordinate RCU topics with Paul
> >> McKenney.
> > 
> > Sounds very good!  The RCU topics that occur to me immediately include:
> > 
> > o	How do we tell compilers about RCU's memory-ordering requirements?
> > 	Follow up to http://lwn.net/Articles/586838/ and
> > 	https://lwn.net/Articles/588300/.  This could potentially
> > 	converge before August, but the odds do not look all that
> > 	favorable.  Might be an interesting discussion of the
> > 	interaction between the kernel and compiler, though perhaps
> > 	in the Chinese sense.  ;-)
> > 
> > o	What use cases are not supported well, and what should we be
> > 	doing to better support them, in RCU or otherwise?  Without
> > 	some reasonably controversial proposals, this aspect seems
> > 	unlikely to be LKS material.
> > 
> > o	Can we do a better job of automatically catching RCU usage
> > 	bugs?  Or, for that matter, RCU bugs!
> > 
> > Other thoughts for topics?
> 
> It seems, from a user's perspective, that an RCU stall is one
> the most user unfriendly things to be on the receiving end of.
> Since it trips an NMI to backtrace each core, on a larger system
> a person is faced with screens and screens of (mostly irrelevant)
> backtrace.  I'm not sure what to suggest to improve things, and
> maybe there really isn't anything that can be done, but IMHO it
> might be worth discussing...

Certainly an area needing improvement, no argument there!

I could imagine boot-time or run-time selection of the stack-dump
strategy (no stack dump, dump current stack, dump only stacks of
stalled CPUs and/or tasks, dump all CPU stacks, dump all task
stacks, dump randomly selected subset of one of the above) as
well as the mechanism (NMI vs. grovel around in other CPU's/task's
stack).  Maybe other things as well.

Other thoughts?

							Thanx, Paul

> Paul.
> --
> 
> 
> > 
> > 							Thanx, Paul
> > 
> > _______________________________________________
> > Ksummit-discuss mailing list
> > Ksummit-discuss@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> > 
>