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

From: Ingo Molnar
Date: Wed Sep 27 2006 - 05:10:06 EST

* Eric W. Biederman <ebiederm@xxxxxxxxxxxx> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at