linux-kernel - Re: per-cpu operation madness vs validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Jul 2011 11:53:09 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: per-cpu operation madness vs validation

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/