linux-kernel - [PATCH 0/3] changes to enable lockless lockref on s390

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-next>] [day] [month] [year] [list]

Date:	Fri, 27 Sep 2013 10:03:51 +0200
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tony Luck <tony.luck@...el.com>, Waiman Long <waiman.long@...com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: [PATCH 0/3] changes to enable lockless lockref on s390

Hi all,

enabling the new lockless lockref variant on s390 would have been trivial
until Tony Luck added a cpu_relax() call into the CMPXCHG_LOOP(), with
d472d9d9 "lockref: Relax in cmpxchg loop".

As already mentioned cpu_relax() is very expensive on s390 since it yields()
the current virtual cpu. So we are talking of several thousand cycles.
Considering this enabling the lockless lockref variant would contradict the
intention of the new semantics. And also some quick measurements show
performance regressions of 50% and more.

Simply removing the cpu_relax() call again seems also not very desireable
since Waiman Long reported that for some workloads the call improved
performance by 5%.

So let's go for a special cpu_relax() variant which can be overridden by
architectures. We have already an arch_mutex_cpu_relax() variant for the
very same purpose, but especially for mutexes.
Since I wouldn't like to add yet another cpu_relax() variant, e.g.
"arch_lockref_cpu_relax()", rename the already present variant to
cpu_relax_simple(), which can be used for both, mutexes and lockrefs.

Not sure if it would make sense to add a new "linux/processor.h"
include file which includes "asm/processor.h", since there doesn't seem to
be a common file where it is guaranteed that cpu_relax() is available.

I simply added the cpu_relax_simple() define to "linux/spinlock_up.h"
since that one explicitly includes "asm/processor.h" because of cpu_relax().

Heiko Carstens (3):
  mutex,spinlock: rename arch_mutex_cpu_relax() to cpu_relax_simple()
  lockref: use cpu_relax_simple()
  s390: enable ARCH_USE_CMPXCHG_LOCKREF

 arch/Kconfig                      | 2 +-
 arch/s390/Kconfig                 | 3 ++-
 arch/s390/include/asm/mutex.h     | 2 --
 arch/s390/include/asm/processor.h | 2 ++
 arch/s390/include/asm/spinlock.h  | 5 +++++
 include/linux/mutex.h             | 4 ----
 include/linux/spinlock_up.h       | 4 ++++
 kernel/mutex.c                    | 8 ++++----
 lib/lockref.c                     | 2 +-
 9 files changed, 19 insertions(+), 13 deletions(-)

-- 
1.8.3.4

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