On Fri, 30 May 2008, Peter Zijlstra wrote:
> Take for instance kmem_cache_cpu, you currently serialize that by strict
> per-cpu-ness and disabling preemption.
Right. The preemption in the fast paths could go away. Would be more
difficult to do in the slow paths.
> The problem is that the preempt-off sections are rather long - so what
> we do is add a lock (mutex) and serialize that way - ignoring the cpu
> affinity.
long? What is so expensive to process there?
>
> so currently:
>
> preempt_disable();
> c = get_cpu_slab();
>
> do load of stuff on c;
> preempt_enable();
>
>
> where the preempt-off section is rather long, we'd like to change that
> to:
>
>
> c = get_cpu_slab();
>
> do stuff to c;
>
> put_cpu_slab(c);
>
>
> so that we can pick between:
>
>
> !rt
>
> get_cpu_slab(s)
> {
> preempt_disable();
> return THIS_CPU(s->cpu_slab);
> }
>
> put_cpu_slab(c)
> {
> preempt_enable();
> }
>
>
> -rt:
>
> get_cpu_slab(s)
> {
> c = THIS_CPU(s->cpu_slab);
> spin_lock(&c->lock); // <-- really a PI-mutex
> }
>
> put_cpu_slab(c)
> {
> spin_unlock(&c->lock);
> }
>
>
> Also, it explicitly ties the preempt-off section to the data used in
> case of !rt, which in turn allows for the direct conversion to the
> locked version.
Ahh. Okay. This would make the lockless preemptless fastpath impossible
because it would have to use some sort of locking to avoid access to the
same percpu data from multiple processor?
--
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
