* HAVE_CMPXCHG_LOCAL arch support.
[not found] ` <20150610145804.GG2753@linux-mips.org>
@ 2015-06-10 15:57 ` Ralf Baechle
2015-06-10 16:00 ` Peter Zijlstra
2015-06-10 16:36 ` Generic kernel features that need architecture(mips) support Xose Vazquez Perez
1 sibling, 1 reply; 5+ messages in thread
From: Ralf Baechle @ 2015-06-10 15:57 UTC (permalink / raw
To: Xose Vazquez Perez
Cc: linux-arch, linux-mips, linux-kernel, Ingo Molnar, Peter Zijlstra
On Wed, Jun 10, 2015 at 04:58:04PM +0200, Ralf Baechle wrote:
> On Mon, Jun 08, 2015 at 03:14:43PM +0200, Xose Vazquez Perez wrote:
>
> > If there is anything wrong, please report it in this thread:
> > https://marc.info/?t=143332955700003
>
>
> > locking/ cmpxchg-local : TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
>
> This one was easy - we have the functions in the code just no "select
> HAVE_CMPXCHG_LOCAL" Kconfig.
Something's wrong there. The new file
Documentation/features/locking/cmpxchg-local/arch-support.txt in linux-next
claims correctly that only s390 and x86 define HAVE_CMPXCHG_LOCAL. And a
git grep -w cmpxchg_local finds that in addition to these alpha, arm, arm64,
avr32, blackfin, c6x, frv, ia64, m32r, m68k, mips, parisc, powerpc, sparc,
unicore32 and xtensa define cmpxchg_local.
These architectures seem to not define cmpxchg_local in their arch/ dir:
arc cris hexagon metag microblaze mn10300 nios2 openrisc score sh tile um
Microblaze and nios2 include <asm-generic/cmpxchg.h> into their arch
cmpxchg.h so they get a definition of these functions but don't define
HAVE_CMPXCHG_LOCAL. Peter Zijlstra said it the local versions are ~ 20
cycles faster on x86 than the "global" version. But I've found one user
of cmpxchg_local, mm/vmstat.c and one user of cmpxchg64_local,
drivers/iommu/intel-iommu.c. Sure, fixing the issue was trivial for me
on MIPS but is having cmpxchg{,64}_local actually worth it?
Cheers,
Ralf
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HAVE_CMPXCHG_LOCAL arch support.
2015-06-10 15:57 ` HAVE_CMPXCHG_LOCAL arch support Ralf Baechle
@ 2015-06-10 16:00 ` Peter Zijlstra
0 siblings, 0 replies; 5+ messages in thread
From: Peter Zijlstra @ 2015-06-10 16:00 UTC (permalink / raw
To: Ralf Baechle
Cc: Xose Vazquez Perez, linux-arch, linux-mips, linux-kernel,
Ingo Molnar
On Wed, 2015-06-10 at 17:57 +0200, Ralf Baechle wrote:
> On Wed, Jun 10, 2015 at 04:58:04PM +0200, Ralf Baechle wrote:
>
> > On Mon, Jun 08, 2015 at 03:14:43PM +0200, Xose Vazquez Perez wrote:
> >
> > > If there is anything wrong, please report it in this thread:
> > > https://marc.info/?t=143332955700003
> >
> >
> > > locking/ cmpxchg-local : TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
> >
> > This one was easy - we have the functions in the code just no "select
> > HAVE_CMPXCHG_LOCAL" Kconfig.
>
> Something's wrong there. The new file
> Documentation/features/locking/cmpxchg-local/arch-support.txt in linux-next
> claims correctly that only s390 and x86 define HAVE_CMPXCHG_LOCAL. And a
> git grep -w cmpxchg_local finds that in addition to these alpha, arm, arm64,
> avr32, blackfin, c6x, frv, ia64, m32r, m68k, mips, parisc, powerpc, sparc,
> unicore32 and xtensa define cmpxchg_local.
>
> These architectures seem to not define cmpxchg_local in their arch/ dir:
>
> arc cris hexagon metag microblaze mn10300 nios2 openrisc score sh tile um
>
> Microblaze and nios2 include <asm-generic/cmpxchg.h> into their arch
> cmpxchg.h so they get a definition of these functions but don't define
> HAVE_CMPXCHG_LOCAL. Peter Zijlstra said it the local versions are ~ 20
> cycles faster on x86 than the "global" version. But I've found one user
> of cmpxchg_local, mm/vmstat.c and one user of cmpxchg64_local,
> drivers/iommu/intel-iommu.c. Sure, fixing the issue was trivial for me
> on MIPS but is having cmpxchg{,64}_local actually worth it?
If you traverse the obfuscation chain a little, you'll find that
local_cmpxchg() is implemented using cmpxchg_local(), and there are a
few more users of that.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Generic kernel features that need architecture(mips) support
[not found] ` <20150610145804.GG2753@linux-mips.org>
2015-06-10 15:57 ` HAVE_CMPXCHG_LOCAL arch support Ralf Baechle
@ 2015-06-10 16:36 ` Xose Vazquez Perez
2015-06-11 6:24 ` Ingo Molnar
1 sibling, 1 reply; 5+ messages in thread
From: Xose Vazquez Perez @ 2015-06-10 16:36 UTC (permalink / raw
To: Ralf Baechle; +Cc: linux-mips, Ingo Molnar, linux-arch, linux-api, LKML
On 06/10/2015 04:58 PM, Ralf Baechle wrote:
> How are the documentation files in Documentation/features/ maintained?
> They were automatically generated so I wonder if I have to take care
> of anything.
CC: Ingo and related ml.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Generic kernel features that need architecture(mips) support
2015-06-10 16:36 ` Generic kernel features that need architecture(mips) support Xose Vazquez Perez
@ 2015-06-11 6:24 ` Ingo Molnar
2015-06-11 13:20 ` Jonathan Corbet
0 siblings, 1 reply; 5+ messages in thread
From: Ingo Molnar @ 2015-06-11 6:24 UTC (permalink / raw
To: Xose Vazquez Perez, Jonathan Corbet
Cc: Ralf Baechle, linux-mips, linux-arch, linux-api, LKML
(Jon Cc:-ed)
* Xose Vazquez Perez <xose.vazquez@gmail.com> wrote:
> On 06/10/2015 04:58 PM, Ralf Baechle wrote:
>
> > How are the documentation files in Documentation/features/ maintained?
> > They were automatically generated so I wonder if I have to take care
> > of anything.
>
> CC: Ingo and related ml.
So changes to Documentation/features/ should come as simple patches done from hand
editing, there's no need to preserve any initial (half-)automated generation.
Formatting should be preserved so that Documentation/features/list-arch.sh still
works as before.
Jon: would you like to receive all patches to Documentation/features/ so you can
collect them in the documentation tree, or can maintainers patch it as part of any
feature work that affects the tables? I think it's all finegrained enough to not
create conflicts. That way they would become partly self-maintaining. (Or at least
one can always hope! ;-)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Generic kernel features that need architecture(mips) support
2015-06-11 6:24 ` Ingo Molnar
@ 2015-06-11 13:20 ` Jonathan Corbet
0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Corbet @ 2015-06-11 13:20 UTC (permalink / raw
To: Ingo Molnar
Cc: Xose Vazquez Perez, Ralf Baechle, linux-mips, linux-arch,
linux-api, LKML
On Thu, 11 Jun 2015 08:24:53 +0200
Ingo Molnar <mingo@kernel.org> wrote:
> Jon: would you like to receive all patches to Documentation/features/ so you can
> collect them in the documentation tree, or can maintainers patch it as part of any
> feature work that affects the tables? I think it's all finegrained enough to not
> create conflicts. That way they would become partly self-maintaining. (Or at least
> one can always hope! ;-)
I sort of figured I'd handle it the way I do the rest of Documentation/ —
I'm happy to herd the patches, but I also have no problem staying out of
the way when other maintainers reach into it.
jon
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-06-11 13:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <55759543.1010408@gmail.com>
[not found] ` <20150610145804.GG2753@linux-mips.org>
2015-06-10 15:57 ` HAVE_CMPXCHG_LOCAL arch support Ralf Baechle
2015-06-10 16:00 ` Peter Zijlstra
2015-06-10 16:36 ` Generic kernel features that need architecture(mips) support Xose Vazquez Perez
2015-06-11 6:24 ` Ingo Molnar
2015-06-11 13:20 ` Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).