Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0

[Daniel Walker]

On Wed, 2004-10-13 at 17:24, Ingo Molnar wrote:
> To solve all these fundamental problems, i improved/fixed/changed all of
> these locking methods to be preemption-friendly. Most of the time it was
> necessary to introduce an additional API variant because e.g.
> rcu_read_lock() is anonymous (it doesnt identify the data protected), so
> i introduced a variant that takes the write-lock as an argument. In the
> PREEMPT_REALTIME case we can thus properly serialize on that lock.

When I was reviewing this it seemed like it would be possible to keep
RCU anonymous by moving the callback processing out of the tasklet . The
reason it was moved into a tasklet was to reduce latency. But if you
serialize it like you have, aren't you removing all the benefits of the
RCU type lock in those section that are converted to the new API ?


> For per-cpu variables i introduced a new API variant that creates a
> spinlock-array for the per-cpu-variable, and users must make sure the
> cpu field doesnt change. Migration to another CPU can happen within the
> critical section, but 'statistically' the variable is still per-CPU and
> update correctness is fully preserved.

Why not have a per cpu mutex instead of a per variable per cpu mutex?
I'm not sure what the trade off are, except size.




Daniel

-
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/