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



On Tue, Sep 26, 2006 at 08:55:41PM -0600, Eric W. Biederman wrote:
Bill Huey (hui) <billh@xxxxxxxxxxxxxxxxx> writes:
This patch moves put_task_struct() reaping into a thread instead of an
RCU callback function as discussed with Esben publically and Ingo privately:

Stupid question.

It's a great question actually.

Why does the rt tree make all calls to put_task_struct an rcu action?
We only need the rcu callback from kernel/exit.c

Because the conversion of memory allocation routines like kmalloc and kfree aren't
safely callable within a preempt_disable critical section since they were incompletely
converted in the -rt. It can run into the sleeping in atomic scenario which can result
in a deadlock since those routines use blocking locks internally in the implementation
now as a result of the spinlock_t conversion to blocking locks.

Nothing else needs those semantics.

Right, blame it on the incomplete conversion of the kmalloc and friends. GFP_ATOMIC is
is kind of meaningless in the -rt tree and it might be a good thing to add something
like GFP_RT_ATOMIC for cases like this to be handled properly and restore that particular
semantic in a more meaningful way.

I agree that put_task_struct is the most common point so this is unlikely
to remove your issues with rcu callbacks but it just seems completely backwards
to increase the number of rcu callbacks in the rt tree.

I'm not sure what mean here, but if you mean that you don't like the RCU API abuse then
I agree with you on that. However, Ingo disagrees and I'm not going to argue it with him.
Although, I'm not going stop you if you do. :)

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/