All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julia Cartwright <julia@ni.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kate Stewart <kstewart@linuxfoundation.org>
Subject: Re: [CFP] RT Users Micro-Conf at Linux Plumbers 2017
Date: Tue, 28 Feb 2017 15:40:12 -0600	[thread overview]
Message-ID: <20170228214012.GP1733@jcartwri.amer.corp.natinst.com> (raw)
In-Reply-To: <20170228160432.2f8eecbe@gandalf.local.home>

[-- Attachment #1: Type: text/plain, Size: 4662 bytes --]

On Tue, Feb 28, 2017 at 04:04:32PM -0500, Steven Rostedt wrote:
> On Tue, 28 Feb 2017 14:41:21 -0600 Julia Cartwright <julia@ni.com> wrote:
> > > A month later there will be a Real-Time get together in Prague, that
> > > would be perfect to be able to bring together a list of issues that
> > > users may have and present this to the PREEMPT_RT kernel developers.  
> > 
> > Having LPC host this seems a bit strange, given your defined audience
> > (users vs. kernel developers).  Perhaps it would be more effective as a
> 
> I don't find it strange at all. There should be more "users" at
> plumbers. LPC is about discussion and not presentations. When users and
> developers get together, it should be a discussion.
> 
> > session in the Open Source Summit track, or at the very least, if
> > attendees at the OSS Summit were able to attend the miniconference w/o
> > the purchase of a LPC badge.
> 
> I think a badge would still be worth purchasing. Having the ability to
> help influence development is a worthy goal.

I didn't mean to make it sound like I didn't consider the LPC badge to
be worth it.  LPC is one of my favorite conferences to attend! Anyone
who asks me which Linux conferences to attend, LPC is always top on my
list.

However, from my experience, the attendees at LPC are largely already
kernel engineers, or other low-level usermode people.  I suppose it's a
question of what "users" you are looking for.

That doesn't necessarily include people who are domain-experts in RTOS
applications but are relatively new to Linux; or people who use a
distro-packaged RT kernels for professional audio but have run into a
few minor snags; or ...

> > > Are people willing to participate and have a discussion on what works
> > > and what doesn't work with PREEMPT_RT. Be able to share horror stories
> > > and work arounds with each other and perhaps come up with better
> > > solutions. I will take what comes out of this with me to Prague and
> > > perhaps be able to influence the development of PREEMPT_RT to address
> > > any issues that arise.  
> > 
> > As a brainstorming of potential content, here's what I'd like to see as
> > an attendee (certainly willing to present where appropriate too!):
> > 
> >   1. Debugging case studies:
> > 
> > There are a ton of debugging/visualizing/tracing tools out there
> > available for finding latency problems.  Too many tools; some with
> > overlapping purpose, and some better than others.  It would be an
> > interesting exercise to have a few folks demonstrate the complete
> > identification, debugging, and fix of a performance problem on RT,
> > complete with a walkthrough of what tools were used.
> 
> Note, LPC is about discussions and not presentations or tutorials.
> Although, I could submit a talk that would hopefully be a good
> introduction into what the plumbers track would be like. I could maybe
> get it accepted for the "shared" day (talks for both plumbers and Open
> Source Summit attendees).
> 
> If you can create a discussion out of debugging tools. "Here's what I
> have, is there a better way to do this?"

Yes, I didn't mean to say to suggest a session with a bunch of
presentations.  I'm only suggesting a presentation as a means to
facilitate meaningful discussions.  Having a ground to start with (a
real-life debugging scenario), I think is a good way to get there.

> >   2. What to consider when designing the priority scheme of your system
> >      (application threads, irqthreads, RCU threads, ...)
>
> I would turn this into something like "here's my work arounds to my
> problems, are there better ways to do this?"
>
> >
> >   3. An enumeration of "knobs" which impact RT behavior
> >
> > Where knobs are any of the compile-time or run-time configuration
> > parameters and how they impact determinism (I'm thinking things we've
> > run into like IRQSOFF tracing, timerslack, the bizarre
> > /dev/cpu_dma_latency, etc).
>
> "here's what I've done, are there better ways to do this?"
>
> Hmm, I'm seeing a trend here ;-)

Certainly.

> > > There's also talk about having this combined with a Safety Critical
> > > session focused on PREEMPT_RT.
> > >
> > > Are people interesting in attending such an event? If so, I'll submit a
> > > proposal for having such a Micro-Conference at Linux Plumbers. If not,
> > > I wont bother wasting any time on it.  
> > 
> > Sounds good to me!  Let me know where I can help.
> 
> I rather have you tell us were you want to help :)

I'd happily talk to/facilitate discussions on the topics I mentioned
above.

   Julia

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2017-02-28 21:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 22:25 [CFP] RT Users Micro-Conf at Linux Plumbers 2017 Steven Rostedt
2017-02-28 20:41 ` Julia Cartwright
2017-02-28 21:04   ` Steven Rostedt
2017-02-28 21:40     ` Julia Cartwright [this message]
2017-02-28 21:52       ` Steven Rostedt
     [not found] ` <CAFTL4hy7GtKkD7AAwPP72oNeGAGg4FLMJkaTv80CJkqpY3xehw@mail.gmail.com>
2017-03-02  2:08   ` Steven Rostedt
2017-03-02 14:10     ` Staffan Tjernstrom
2017-03-08 12:57     ` Frederic Weisbecker

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=20170228214012.GP1733@jcartwri.amer.corp.natinst.com \
    --to=julia@ni.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.