Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

[Ingo Molnar <mingo@elte.hu>]

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> Yes I am.  The motivator would be the RT work but I don't see a reason 
> why the it couldn't be put in the mainline kernel.  If not at least we 
> need the big fat comment in the mainline kernel that says 
> put_task_struct must be safe to call with interrupts disabled.
> 
> The way the code is structured now it deviates from the mainline 
> kernel in more than just changing locking behavior.  Which is what 
> brought me into this conversation in the first place.  So removing 
> that point of discord would be good.

well, this is one of those few cases (out of ~50,000 lock uses in the 
kernel) where such a change was unavoidable: put_task_struct() is used 
in the scheduler context-switch path. (see sched.c:finish_task_switch())

So that's why i first turned it into a separate, extra delayed-free via 
the "desched thread", and later on picked up the RCUification from Paul 
McKenney. The RCUification was the simpler (and hence easier to 
maintain) change. There is no problem with putting this into the RCU 
path on PREEMPT_RT, as this is a resource-freeing act. I.e. whatever 
'delay' there might be in RCU processing, it does not impact program 
logic. I agree with you that on !PREEMPT_RT there's no reason to 
complicate things with an extra layer of indirection.

	Ingo