Messages in this thread | | | Date | Tue, 11 Jul 2006 10:45:52 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH -rt] catch put_task_struct RCU handling up to mainline |
| |
On Mon, Jul 10, 2006 at 09:09:35PM +0100, Esben Nielsen wrote: > On Mon, 10 Jul 2006, Paul E. McKenney wrote: > >On Mon, Jul 10, 2006 at 07:10:49PM +0100, Esben Nielsen wrote: > >>On Mon, 10 Jul 2006, Paul E. McKenney wrote: > >>>On Sat, Jul 08, 2006 at 02:59:37PM +0100, Esben Nielsen wrote: > > > >[ . . . ] > > > >>>>The work should be defered to a low priority task. Using rcu is > >>>>probably overkill because it also introduces other delays. A tasklet > >>>>or a dedicated task would be better. > >>> > >>>Agreed -- if there is in fact a legitimate non-error code path, then > >>>a patch that used some deferral mechanism would be good. But RCU is > >>>overkill, and misleading overkill at that! > >>> > >> > >>I think this is a legitimate situation. lock 1 is owned by B which is > >>blocked on lock 2 which is owned by C > >> > >> CPU1: CPU2 > >> RT task A locks lock 1 C runs something > >> A boosts B to RT > >> A does get_task_struct B > >> A enables interrupts C unlocks lock 2 > >> An very long interrupt is running B unlocks lock 2 > >> B unlocks lock 1 > >> B is deboosted > >> B exits > >> A gets CPU1 again > >> A does put_task_struct B > >> > >>I don't know if the timing is realistic, but theoretically it is possible. > >>It might also be possible the B exits on another CPU even without the long > >>interrupt handler. If A has cpu affinity to CPU1 it is enough if a higher > >>priority task preempts it on CPU1. > > > >For this to happen, either A has to be at a lower priority than the irq > >tasks or the interrupt has to be a hard irq (e.g., scheduling clock > >interrupt). In the first case, the added cleanup processing seems > >inconsequential compared to (say) an interrupt doing network protocol > >processing. In the second case, B does not do its put_task_struct() > >until after the hard irq returns (because the put_task_struct() is invoked > >from a call_rcu() callback), which makes the above scenario unlikely, > >though perhaps not impossible. > > > >If the second scenario is in fact possible, would you be willing to > >supply the appropriate deferral code? I believe we both agree that RCU > >is not really the right deferral mechanism in this situation. > > > > Let your patch go through. I'll stop complaining :-) > Is there anywhere where we can make a list of known issues like this? > I can't promise I will get time to fix this one :-(
;-)
One possibility would be a file in the Documentation directory. Another would be something on the web, but a file in the Documentation directory would have the advantage of being synched with the -rt version.
Thanx, Paul - 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/
| |