On Fri, Jul 07, 2006 at 11:56:00PM +0100, Esben Nielsen wrote:
> On Fri, 7 Jul 2006, Paul E. McKenney wrote:
>
> >Hello!
> >
> >Due to the separate -rt and mainline evolution of RCU signal handling,
> >the -rt patchset now makes each task struct go through two RCU grace
> >periods, with one call_rcu() in release_task() and with another
> >in put_task_struct(). Only the call_rcu() in release_task() is
> >required, since this is the one that is associated with tearing down
> >the task structure.
> >
> >This patch removes the extra call_rcu() in put_task_struct(), synching
> >this up with mainline. Tested lightly on i386.
> >
>
> The extra call_rcu() has an advantage:
> It defers work away from the task doing the last put_task_struct().
> It could be a priority 99 task with hard latency requirements doing
> some PI boosting, forinstance. The extra call_rcu() defers non-RT work to
> a low priority task. This is in generally a very good idea in a real-time
> system.
> So unless you can argue that the work defered is as small as the work of
> doing a call_rcu() I would prefer the extra call_rcu().
I would instead argue that the only way that the last put_task_struct()
is an unrelated high-priority task is if it manipulating an already-exited
task. In particular, I believe that the sys_exit() path prohibits your
example of priority-boosting an already-exited task by removing the
exiting task from the various lists before doing the release_task()
on itself.
Please let me know what I am missing here!
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
