Messages in this thread | | | Date | Wed, 30 Apr 2014 12:07:39 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [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/
| |