public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: David Howells <dhowells@redhat.com>
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-am33-list@redhat.com, linux-kernel@vger.kernel.org
Subject: [PATCH] mn10300: select generic atomic64_t support
Date: Tue, 14 Aug 2012 23:17:04 +0800	[thread overview]
Message-ID: <20120814151704.GA17668@localhost> (raw)

Rationals from Eric:

So I just looked a little deeper and it appears architectures that do
not support atomic64_t are broken.

The generic atomic64 support came in 2009 to support the perf subsystem
with the expectation that all architectures would implement atomic64
support.

Furthermore upon inspection of the kernel atomic64_t is used in a fair
number of places beyond the performance counters:

block/blk-cgroup.c
drivers/acpi/apei/
drivers/block/rbd.c
drivers/crypto/nx/nx.h
drivers/gpu/drm/radeon/radeon.h
drivers/infiniband/hw/ipath/
drivers/infiniband/hw/qib/
drivers/staging/octeon/
fs/xfs/
include/linux/perf_event.h
include/net/netfilter/nf_conntrack_acct.h
kernel/events/
kernel/trace/
net/mac80211/key.h
net/rds/

The block control group, infiniband, xfs, crypto, 802.11, netfilter.
Nothing quite so fundamental as fs/namespace.c but definitely in
multiplatform-code that should work, and is already broken on those
architecutres.

Looking at the implementation of atomic64_add_return in lib/atomic64.c
the code looks as efficient as these kinds of things get.

Which leads me to the conclusion that we need atomic64 support on all
architectures.

CC: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 arch/mn10300/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux.orig/arch/mn10300/Kconfig	2012-08-03 15:36:21.391560778 +0800
+++ linux/arch/mn10300/Kconfig	2012-08-14 22:53:14.751795832 +0800
@@ -8,6 +8,7 @@ config MN10300
 	select HAVE_ARCH_KGDB
 	select HAVE_NMI_WATCHDOG if MN10300_WD_TIMER
 	select GENERIC_CLOCKEVENTS
+	select GENERIC_ATOMIC64
 
 config AM33_2
 	def_bool n

             reply	other threads:[~2012-08-14 15:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-14 15:17 Fengguang Wu [this message]
2012-12-28 22:15 ` [PATCH] mn10300: select generic atomic64_t support Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120814151704.GA17668@localhost \
    --to=fengguang.wu@intel.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-am33-list@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yasutake.koichi@jp.panasonic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox