From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: <paulmck@linux.vnet.ibm.com>, Josh Triplett <josh@joshtriplett.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] Nominations for Kernel Summit
Date: Fri, 9 May 2014 12:46:04 -0400 [thread overview]
Message-ID: <536D064C.3050308@windriver.com> (raw)
In-Reply-To: <20140508001624.GA21038@linux.vnet.ibm.com>
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...
Paul.
--
>
> Thanx, Paul
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
next prev parent reply other threads:[~2014-05-09 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 16:56 Josh Triplett
2014-05-02 17:44 ` tytso
2014-05-08 0:16 ` Paul E. McKenney
2014-05-09 16:46 ` Paul Gortmaker [this message]
2014-05-09 17:39 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536D064C.3050308@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=josh@joshtriplett.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox