* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> What this does is make a strong connection between data and
> concurrency control. Your proposed scheme weakens the
> data<->concurrency relation instead of making it stronger.
and that's not just an issue for -rt but also for general kernel
maintainability: opaque APIs weaken our data structures because it's not
apparent what is done exactly why. In that sense a
spin_lock(&data->lock) is as clear as it gets.
> One sign of that is that you replace things like get_cpu with explicit
> preempt_disable().
>
> We're trying to get rid of as many explicit preempt_disable()s as
> possible - in the light of -rt, preempt_disable() is as bad as the BKL
> in that its opaque - unrelated to a specific data set.
>
> *lightbulb*
>
> Ah, we could still do the above by writing:
>
> struct kmem_cache_cpu *get_cpu_slab(struct kmem_cache *s)
> {
> struct kmem_cache_cpu *c = THIS_CPU(s->cpu_slab);
> spin_lock(&c->lock);
> return c;
> }
>
> void put_cpu_slab(struct kmem_cache_cpu *c)
> {
> spin_unlock(&c->lock);
> }
>
> Would it be possible to re-structure your API to also have these get/put
> methods instead of just a get?
seconded.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
