* Eric W. Biederman <[email protected]> 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
-
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]
