Re: [RFC 09/16] kgr: mark task_safe in some kthreads

[Mike Galbraith]

On Wed, 2014-05-14 at 12:32 -0400, Tejun Heo wrote: 
> Hello, Jiri, Vojtech.
> 
> On Wed, May 14, 2014 at 05:15:01PM +0200, Vojtech Pavlik wrote:
> > On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
> > > I see the worst case scenario. (For curious readers, it is for example
> > > this kthread body:
> > > while (1) {
> > >   some_paired_call(); /* invokes pre-patched code */
> > >   if (kthread_should_stop()) { /* kgraft switches to the new code */
> > >     its_paired_function(); /* invokes patched code (wrong) */
> > >     break;
> > >   }
> > >   its_paired_function(); /* the same (wrong) */
> > > })
> > > 
> > > What to do with that now? We have come up with a couple possibilities.
> > > Would you consider try_to_freeze() a good state-defining function? As it
> > > is called when a kthread expects weird things can happen, it should be
> > > safe to switch to the patched version in our opinion.
> > > 
> > > The other possibility is to patch every kthread loop (~300) and insert
> > > kgr_task_safe() semi-manually at some proper place.
> > > 
> > > Or if you have any other suggestions we would appreciate that?
> > 
> > A heretic idea would be to convert all kernel threads into functions
> > that do not sleep and exit after a single iteration and are called from
> > a central kthread main loop function. That would get all of
> 
> Or converting them to use workqueues instead.  Converting majority of
> kthread users to workqueue is probably a good idea regardless of this
> because workqueues are far easier to get right and give clear
> delineation boundary between execution instances between which it's
> safe to freeze and shutdown (and possibly to patch the work function).
> Let alone overall lower overhead.  I converted some and was planning
> on converting most of them but never got around ot it.

Hm.  The user would need to be able to identify and prioritize the
things, and have his settings stick.  Any dynamic pool business doing
allocations and/or munging priorities would be highly annoying.

I saw a case where dynamic workers inflicted a realtime regression on a
user (but what they were getting away with previously was.. horrid).

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/