On Tue, 23 May 2017 13:00:35 -0700 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> > > Unfortunately, it does not work, as I should have known ahead of > > > time from the dyntick-idle experience. Not all context switches > > > go through context_switch(). :-/ > > > > Wait. What context switch doesn't go through a context switch? Or do > > you mean a user/kernel context switch? > > I mean that putting printk() before and after the call to > context_switch() can show tasks switching out twice without switching > in and vice versa. No sign of lost printk()s, and I also confirmed > this behavior using a flag in task_struct. I hope you meant trace_printk()s' as printk is a huge overhead and can cause side effects. > > One way that this can happen on some architectures is via the "helper" > mechanism, where the task sleeps normally, but where a later interrupt > or exception takes on its context "behind the scenes" in the arch > code. This is what messed up my attempt to use a simple > interrupt-nesting counter for RCU dynticks some years back. What I > counted on there was that the idle loop would never do that sort of > thing, so I could zero the count when entering idle from process > context. > > But I have not yet found a similar trick for counting voluntary > context switches. > > I also tried making context_switch() look like a momentary quiescent > state, but of course that means that tasks that block forever also > block the grace period forever. At which point, I need to scan the > task list to find them. And that pretty much brings me back to the > current RCU-tasks implementation. :-/ > Nothing should block in a preempted state forever, and if it does, that means we want to wait forever. Because it could be preempted on the trampoline. -- Steve
