Re: per-cpu operation madness vs validation

[Christoph Lameter]

On Wed, 27 Jul 2011, Peter Zijlstra wrote:

> > regardless of the execution context. The primary initial motivation was
> > incrementing per cpu counters without having to disabling interrupts
> > and/or preemption and it grew from there.
>
> I think you need to look at 20b876918c065818b3574a426d418f68b4f8ad19 and
> try again. You removed get_cpu_var()/put_cpu_var() and replaced it with
> naked preempt_disable()/preempt_enable(). That's loosing information
> right there.

It avoided storing the cpu variable.

> Also, I think if you do s/__this_cpu/this_cpu/ on that function you can
> simply drop the preempt_enable/disable things.

Ok that would be good. Could you do a patch like that?

> > The atomic per cpu operations (like the this_cpu_cmpxchg) allow the
> > construction of cheap sections that would satisfy your goals too (with
> > some work and the use of transaction ids instead of locking). See the slub
> > fastpath f.e.
>
> The slub fastpath is a shining example of crap. Its horrid code and
> there was nothing wrong with actually disabling preemption over it, even
> for -rt. Sure you made it go faster, but thats not the point.

The faster is the main point. Serialization overhead is a major cause of
slowdown. Sure it may look unusual to you but over time this will clear
up and become easier to use.

> Most of the slub problems with -rt are in the slow path where you still
> have per-cpu assumptions and keep preempt/irqs disabled.

There are patches pending that continue to remove these things from the
slowpath. With the proposed changes pending for 3.1 we will have a free
slowpath that does not require irq disable or preempt disable.

> I don't think it is possible, nor desirable, to wreck all per-cpu usage
> in the kernel that way.

What in the world are you talking about? No major change to basic
get_cpu/put_cpu and friends is necessary. The __this_cpu ops is a new
thing true but it also replaces open coded increments in preempt sections
that then have per cpu increments in non preempt sections.
--
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/