lkml.org 
[lkml]   [2014]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 09/16] kgr: mark task_safe in some kthreads
On Wed, Apr 30, 2014 at 08:33:27PM +0200, Vojtech Pavlik wrote:
> On Wed, Apr 30, 2014 at 09:55:32AM -0700, Paul E. McKenney wrote:
> > On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> > > Some threads do not use kthread_should_stop. Before we enable a
> > > kthread support in kgr, we must make sure all those mark themselves
> > > safe explicitly.
> >
> > Would it make sense to bury kgr_task_safe() in wait_event_interruptible()
> > and friends? The kgr_task_safe() implementation looks pretty lightweight,
> > so it should not be a performance problem.
>
> For userspace tasks, the kGraft in progress flag is cleared when
> entering or exiting userspace. At that point it is safe to switch the
> task to a post-patch world view.
>
> For kernel threads, it's a bit more complicated: They never exit the
> kernel, they keep executing within the kernel continuously. The
> kgr_task_safe() call is thus inserted at a location within the main loop
> where a 'new loop' begins - where there are no dependencies on results
> of calls of functions from the previous loop.
>
> Hence, putting kgr_task_safe() into every wait_event_interruptible()
> wouldn't work, only a few of them are at that strategic spot where a
> 'new loop' can be indicated to kGraft.
>
> The reason kgr_task_safe() is called from within the condition
> evaluation statement in wait_event_interruptible() in this patch is
> because we want it to be called as soon as a new loop begins - even if
> that loop is empty because the condition to stop waiting has not been
> met.
>
> This also means that kGraft currently cannot patch the main loops of
> kernel threads themselves as the thread of execution never exits them.
>
> Jiří (Slabý) has some ideas about how to do without calling
> kgr_task_safe() from within the kernel thread main loops, but for now,
> the goal is to keep things simple and easy to understand.

OK, from an RCU perspective:

Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

> > One reason might this might be a bad idea is that there are calls to
> > wait_event_interruptible() all over the place, which might therefore
> > constrain where grafting could be safely done. That would be fair enough,
> > but does that also imply new constraints on where kthread_should_stop()
> > can be invoked? Any new constraints might not be a big deal given that
> > a very large fraction of the kthreads (and maybe all of them) invoke
> > kthread_should_stop() from their top-level function, but would be good
> > to call out.
>
> > So, what is the story?
>
> kGraft currently assumes that kthread_should_stop() is always in a part
> of the main loop which doesn't carry over effect dependencies from the
> previous iteration. This is currently true for all the uses of
> kthread_should_stop(), but indeed it is an additional constraint for the
> future.

Got it. It would be good to document this. ;-)

Thanx, Paul

> Vojtech
>

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

\
 
 \ /
  Last update: 2014-04-30 22:01    [W:0.193 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site