With the introduction of a389d86f7fd09 ("ring-buffer: Have nested events
still record running time stamp"), the timestamps required needing 64-bit
cmpxchg. As some architectures do no even have a 64-bit cmpxchg, the code
for 32-bit architectures used 3 32-bit words that represented
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
From: "Steven Rostedt (Google)"
[ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Link:
https://lore.kernel.org/l
With the introduction of a389d86f7fd09 ("ring-buffer: Have nested events
still record running time stamp"), the timestamps required needing 64-bit
cmpxchg. As some architectures do no even have a 64-bit cmpxchg, the code
for 32-bit architectures used 3 32-bit words that represented
From: "Steven Rostedt (Google)"
As the ring buffer recording requires cmpxchg() to work, if the
architecture does not support cmpxchg in NMI, then do not do any recording
within an NMI.
Signed-off-by: Steven Rostedt (Google)
---
kernel/trace/ring_buffer.c | 6 ++
1 file
Use try_cmpxchg instead of cmpxchg (*ptr, old, new) == old in
rb_insert_pages. x86 CMPXCHG instruction returns success in ZF flag,
so this change saves a compare after cmpxchg (and related move
instruction in front of cmpxchg).
No functional change intended.
Cc: Steven Rostedt
Cc: Masami
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
From: Gao Xiang
commit 4d752e5af63753ab5140fc282929b98eaa4bd12e upstream.
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warning ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3]
On Tue, Apr 06, 2021 at 12:08:55PM +0200, Helge Deller wrote:
> On 4/6/21 6:59 AM, Gao Xiang wrote:
> > From: Gao Xiang
> >
> > commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
> > can generate a sparse warningi ("cast truncates
On 4/6/21 6:59 AM, Gao Xiang wrote:
From: Gao Xiang
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warningi ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3].
The original cod
Am Dienstag, 6. April 2021, 06:59:29 CEST schrieb Gao Xiang:
> From: Gao Xiang
>
> commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
> can generate a sparse warningi ("cast truncates bits from constant
^
> va
From: Gao Xiang
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers")
can generate a sparse warningi ("cast truncates bits from constant
value"), which has been reported several times [1] [2] [3].
The original code worked as expected, but anyway, let silence
To reduce dependence on the MMU write lock, don't rely on the assumption
that the atomic operation in kvm_tdp_mmu_get_root will always succeed.
By not relying on that assumption, threads do not need to hold the MMU
lock in write mode in order to take a reference on a TDP MMU root.
In the root
From: Will Deacon
commit 5ef3fe4cecdf82fdd71ce78988403963d01444d4 upstream.
Our atomic instructions (either LSE atomics of LDXR/STXR sequences)
natively support byte, half-word, word and double-word memory accesses
so there is no need to mask the data register prior to being stored.
From: Will Deacon
commit 4230509978f2921182da4e9197964dccdbe463c3 upstream.
The "L" AArch64 machine constraint, which we use for the "old" value in
an LL/SC cmpxchg(), generates an immediate that is suitable for a 64-bit
logical instruction. However, for cmpxchg() operati
From: Will Deacon
commit 5ef3fe4cecdf82fdd71ce78988403963d01444d4 upstream.
Our atomic instructions (either LSE atomics of LDXR/STXR sequences)
natively support byte, half-word, word and double-word memory accesses
so there is no need to mask the data register prior to being stored.
From: Robin Murphy
commit 8df728e1ae614f592961e51f65d3e3212ede5a75 upstream.
The cmpxchg implementation introduced by commit c342f78217e8 ("arm64:
cmpxchg: patch in lse instructions when supported by the CPU") performs
an apparently redundant register move of [old] to [oldval] in t
From: Will Deacon
commit 4230509978f2921182da4e9197964dccdbe463c3 upstream.
The "L" AArch64 machine constraint, which we use for the "old" value in
an LL/SC cmpxchg(), generates an immediate that is suitable for a 64-bit
logical instruction. However, for cmpxchg() operati
From: Will Deacon
commit 5ef3fe4cecdf82fdd71ce78988403963d01444d4 upstream.
Our atomic instructions (either LSE atomics of LDXR/STXR sequences)
natively support byte, half-word, word and double-word memory accesses
so there is no need to mask the data register prior to being stored.
From: Will Deacon
commit 4230509978f2921182da4e9197964dccdbe463c3 upstream.
The "L" AArch64 machine constraint, which we use for the "old" value in
an LL/SC cmpxchg(), generates an immediate that is suitable for a 64-bit
logical instruction. However, for cmpxchg() operati
On Fri, Feb 26, 2021 at 01:47:20PM +, Chris Down wrote:
> Chris Down writes:
> > I must confess I have no idea of the history of why it was `extern int`
> > in the first place -- my fear was somehow we use cmpxchg.h from a
> > different context. Do you have any idea? :-)
>
> Ok, found where
Chris Down writes:
I must confess I have no idea of the history of why it was `extern
int` in the first place -- my fear was somehow we use cmpxchg.h from a
different context. Do you have any idea? :-)
Ok, found where it's introduced in the pre-git archives: "New file
Matthew Wilcox writes:
Why not just fix it?
diff --git a/arch/ia64/include/uapi/asm/cmpxchg.h
b/arch/ia64/include/uapi/asm/cmpxchg.h
index 5d90307fd6e0..d955a8e3ebde 100644
--- a/arch/ia64/include/uapi/asm/cmpxchg.h
+++ b/arch/ia64/include/uapi/asm/cmpxchg.h
@@ -139,7 +139,7 @@ extern long
On Fri, Feb 26, 2021 at 12:47:58PM +, Chris Down wrote:
> >./include/linux/printk.h:219:5: error: static declaration of 'printk'
> > follows non-static declaration
> >219 | int printk(const char *s, ...)
> > | ^~
> >./arch/ia64/include/uapi/asm/cmpxchg.h:142:14: note:
+ akpm, linux-mm
Hey folks,
Chris Down writes:
With !CONFIG_PRINTK, printk() is static in the header, but ia64's
cmpxchg.h with CONFIG_IA64_DEBUG_CMPXCHG doesn't take this into account
before trying to use it as extern, resulting in a compiler error:
./include/linux/printk.h:219:5: error:
With !CONFIG_PRINTK, printk() is static in the header, but ia64's
cmpxchg.h with CONFIG_IA64_DEBUG_CMPXCHG doesn't take this into account
before trying to use it as extern, resulting in a compiler error:
./include/linux/printk.h:219:5: error: static declaration of 'printk'
follows non-static
old32 = load32;
> new32 = (load32 & ~mask) | (val << shift);
> - load32 = cmpxchg(ptr32, old32, new32);
> + load32 = cmpxchg_local(ptr32, old32, new32);
> } while (load32 != old32);
>
> return (load32 & mask
@@ -41,7 +41,7 @@ unsigned long __xchg_small(volatile void *ptr, unsigned long
val, unsigned int s
do {
old32 = load32;
new32 = (load32 & ~mask) | (val << shift);
- load32 = cmpxchg(ptr32, old32, new32);
+ load32 = cmp
On Tue, Oct 27, 2020 at 05:22:48PM +0100, Arnd Bergmann wrote:
> I have already sent patches to move -Wnested-externs and
> -Wcast-align from W=2 to W=3, and I guess -Wpointer-sign
> could be handled the same way to make the W=2 level useful
> again.
Works for me ;-), thanks!
On Tue, Oct 27, 2020 at 11:32 AM Peter Zijlstra wrote:
>
> On Tue, Oct 27, 2020 at 09:33:32AM +0100, Arnd Bergmann wrote:
> > On Tue, Oct 27, 2020 at 8:47 AM Peter Zijlstra wrote:
> > > On Mon, Oct 26, 2020 at 02:03:06PM -0400, Waiman Long wrote:
> > > > On 10/26/20 12:57 PM, Arnd Bergmann
From: Peter Zijlstra
> Sent: 27 October 2020 10:33
>
> On Tue, Oct 27, 2020 at 09:33:32AM +0100, Arnd Bergmann wrote:
> > On Tue, Oct 27, 2020 at 8:47 AM Peter Zijlstra wrote:
> > > On Mon, Oct 26, 2020 at 02:03:06PM -0400, Waiman Long wrote:
> > > > On 10/26/20 12:57 PM, Arnd Bergmann wrote:
>
On Tue, Oct 27, 2020 at 09:33:32AM +0100, Arnd Bergmann wrote:
> On Tue, Oct 27, 2020 at 8:47 AM Peter Zijlstra wrote:
> > On Mon, Oct 26, 2020 at 02:03:06PM -0400, Waiman Long wrote:
> > > On 10/26/20 12:57 PM, Arnd Bergmann wrote:
> > > Yes, it shouldn't really matter if the value is defined as
On Tue, Oct 27, 2020 at 8:47 AM Peter Zijlstra wrote:
> On Mon, Oct 26, 2020 at 02:03:06PM -0400, Waiman Long wrote:
> > On 10/26/20 12:57 PM, Arnd Bergmann wrote:
> > Yes, it shouldn't really matter if the value is defined as int or u32.
> > However, the only caveat that I see is
On Mon, Oct 26, 2020 at 02:03:06PM -0400, Waiman Long wrote:
> On 10/26/20 12:57 PM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When building with W=2, the build log is flooded with
> >
> > include/asm-generic/qrwlock.h:65:56: warning: pointer targets in passing
> > argument 2 of
On 10/26/20 12:57 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
When building with W=2, the build log is flooded with
include/asm-generic/qrwlock.h:65:56: warning: pointer targets in passing
argument 2 of 'atomic_try_cmpxchg_acquire' differ in signedness [-Wpointer-sign]
On Mon, Oct 26, 2020 at 05:57:51PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When building with W=2, the build log is flooded with
>
> include/asm-generic/qrwlock.h:65:56: warning: pointer targets in passing
> argument 2 of 'atomic_try_cmpxchg_acquire' differ in signedness
>
From: Arnd Bergmann
When building with W=2, the build log is flooded with
include/asm-generic/qrwlock.h:65:56: warning: pointer targets in passing
argument 2 of 'atomic_try_cmpxchg_acquire' differ in signedness [-Wpointer-sign]
include/asm-generic/qrwlock.h:92:53: warning: pointer targets in
On Thu, Sep 03, 2020 at 03:01:22PM +0800, Alex Shi wrote:
> Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use
> cmpxchg4 on it.
>
> Here we mark above 4 arch's NO_CMPXCHG_BYTE, and would add more if we
> found.
>
> This is the first usages of cmpxchg
Hi Robin,
On Fri, Sep 04, 2020 at 10:58:14AM +0100, Robin Murphy wrote:
> On 2020-09-04 10:37, Joerg Roedel wrote:
> > Adding Robin.
>
> Did you miss that I've reviewed this already? :)
>
> https://lore.kernel.org/linux-iommu/3afcc7b2-0bfb-b79c-513f-1beb66c5f...@arm.com/
Hmm, that mail wasn't
Hi Joerg,
On 2020-09-04 10:37, Joerg Roedel wrote:
Adding Robin.
Did you miss that I've reviewed this already? :)
https://lore.kernel.org/linux-iommu/3afcc7b2-0bfb-b79c-513f-1beb66c5f...@arm.com/
Robin.
On Thu, Aug 27, 2020 at 04:43:54PM +0800, Shaokun Zhang wrote:
From: Yuqi Jin
The
Adding Robin.
On Thu, Aug 27, 2020 at 04:43:54PM +0800, Shaokun Zhang wrote:
> From: Yuqi Jin
>
> The performance of the atomic_xchg is better than atomic_cmpxchg because
> no comparison is required. While the value of @fq_timer_on can only be 0
> or 1. Let's use atomic_xchg instead of
'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> >> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> >> flags. It would cause long waiting for sync.
> >>
> >> If we could change the pageblock_flags variable as char, we could
在 2020/9/3 下午4:19, David Hildenbrand 写道:
> On 03.09.20 09:01, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to sync in cmpxc
On 9/3/20 10:40 AM, Alex Shi wrote:
>
>
> 在 2020/9/3 下午4:32, Alex Shi 写道:
>>>
>> I have run thpscale with 'always' defrag setting of THP. The Amean stddev is
>> much
>> larger than a very little average run time reducing.
>>
>> But the left
在 2020/9/3 下午3:29, Max Filippov 写道:
>> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
>> index e997e0119c02..862b008ab09e 100644
>> --- a/arch/xtensa/Kconfig
>> +++ b/arch/xtensa/Kconfig
>> @@ -42,6 +42,7 @@ config XTENSA
>> select MODULES_USE_ELF_RELA
>> select
在 2020/9/3 下午4:32, Alex Shi 写道:
>>
> I have run thpscale with 'always' defrag setting of THP. The Amean stddev is
> much
> larger than a very little average run time reducing.
>
> But the left patch 4 could show the cmpxchg retry reduce from thousands to
> hundreds
在 2020/9/3 下午3:24, Mel Gorman 写道:
> On Thu, Sep 03, 2020 at 03:01:20PM +0800, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to s
On 03.09.20 09:01, Alex Shi wrote:
> pageblock_flags is used as long, since every pageblock_flags is just 4
> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> flags. It would cause
On Thu, Sep 3, 2020 at 12:01 AM Alex Shi wrote:
>
> Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use
> cmpxchg4 on it.
[...]
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig> index
> e00d94b16658..03a6c7fd999d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@
On Thu, Sep 03, 2020 at 03:01:20PM +0800, Alex Shi wrote:
> pageblock_flags is used as long, since every pageblock_flags is just 4
> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> fla
Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use
cmpxchg4 on it.
Here we mark above 4 arch's NO_CMPXCHG_BYTE, and would add more if we
found.
This is the first usages of cmpxchg flase sharing change. We'd better
check more cmpxchg usages in current kernel...
Reported
pageblock_flags is used as long, since every pageblock_flags is just 4
bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
flags. It would cause long waiting for sync.
If we could change the pageblock_flags
在 2020/9/1 下午9:17, Matthew Wilcox 写道:
> On Tue, Sep 01, 2020 at 02:30:51PM +0800, Alex Shi wrote:
>> seems there are couples archs can not do cmpxchg1
>> So update the patch here. And it's easy to fix if more arch issue find here.
>
>> +/*
>> + * cmpxchg
在 2020/9/2 上午1:06, Vlastimil Babka 写道:
>>
>>pageblock pageblock pageblockrc2 rc2
>>rc2
>> 1616-216-3 a b
>> c
>> Duration User 14.81 15.24 14.55
On 9/1/20 4:50 AM, Alex Shi wrote:
> pageblock_flags is used as long, since every pageblock_flags is just 4
> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> flags. It would cause
On Tue, Sep 01, 2020 at 02:30:51PM +0800, Alex Shi wrote:
> seems there are couples archs can not do cmpxchg1
> So update the patch here. And it's easy to fix if more arch issue find here.
> +/*
> + * cmpxchg only support 32-bits operands on the following archs ARMv6,
> SPARC32
&g
ork around multiple arch's cmpxchg
support issue
Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use
cmpxchg4 on it.
arm-linux-gnueabi-ld: mm/page_alloc.o: in function `set_pfnblock_flags_mask':
(.text+0x32b4): undefined reference to `__bad_cmpxchg'
arm-linux-gnueabi-ld: (.t
pageblock_flags is used as long, since every pageblock_flags is just 4
bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
flags. It would cause long waiting for sync.
If we could change the pageblock_flags
+/* cmpxchg only support 32-bits operands on ARMv6. */
+#ifdef CONFIG_CPU_V6
+#define BITS_PER_FLAGS BITS_PER_LONG
+typedef unsigned long pageblockflags_t;
+#else
+#define BITS_PER_FLAGS BITS_PER_BYTE
+typedef unsigned char pageblockflags_t;
+#endif
+
struct zone {
/* Read-mostly fields
U_V6
>> +/* arm v6 has no cmpxchgb function, so still false sharing long
>> word */
>> +old_byte = cmpxchg((unsigned long*)[byte_bitidx], byte,
>> (byte & ~mask) | flags);
>> +#else
>> old_byte = cmpxchg([byte_bitidx], byte, (byte &
_V6
> + byte = (unsigned long)READ_ONCE(bitmap[byte_bitidx]);
> +#else
> byte = READ_ONCE(bitmap[byte_bitidx]);
> +#endif
> for (;;) {
> +#ifdef CONFIG_CPU_V6
> + /* arm v6 has no cmpxchgb function, so still false sharing long
> word */
> +
在 2020/8/19 下午3:55, Anshuman Khandual 写道:
>
>
> On 08/19/2020 11:17 AM, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting ha
(32bit machine) or 16 pageblocks' flags,
>>> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
>>> flags. It would cause long waiting for sync.
>>>
>>> If we could change the pageblock_flags variable as char, we could use
>>> char size cmpxch
On 2020-08-27 09:43, Shaokun Zhang wrote:
From: Yuqi Jin
The performance of the atomic_xchg is better than atomic_cmpxchg because
no comparison is required. While the value of @fq_timer_on can only be 0
or 1. Let's use atomic_xchg instead of atomic_cmpxchg here because we
only need to check
From: Yuqi Jin
The performance of the atomic_xchg is better than atomic_cmpxchg because
no comparison is required. While the value of @fq_timer_on can only be 0
or 1. Let's use atomic_xchg instead of atomic_cmpxchg here because we
only need to check that the value changes from 0 to 1 or from 1
It has been shown that the cmpxchg() for finding space in the cmdq can
be a bottleneck:
- for more CPUs contending the cmdq, the cmpxchg() will fail more often
- since the software-maintained cons pointer is updated on the same 64b
memory region, the chance of cmpxchg() failure increases again
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
gt; > > the following issue on SuperH:
> > >
> > > >> ERROR: modpost: "__cmpxchg_called_with_bad_pointer"
> > > [drivers/phy/ti/phy-tusb1210.ko] undefined!
> > >
> > > Add support for cmpxchg on u8 and u16 pointers.
> > >
> &
>
> > >> ERROR: modpost: "__cmpxchg_called_with_bad_pointer"
> > [drivers/phy/ti/phy-tusb1210.ko] undefined!
> >
> > Add support for cmpxchg on u8 and u16 pointers.
> >
> > [1] https://lore.kernel.org/patchwork/patch/1288894/#1485536
> >
.ko] undefined!
>
> Add support for cmpxchg on u8 and u16 pointers.
>
> [1] https://lore.kernel.org/patchwork/patch/1288894/#1485536
>
> Reported-by: kernel test robot
> Signed-off-by: Liam Beguin
> ---
>
> Hi,
>
> This was reported by the kernel test bot on an
On 19.08.20 09:55, Anshuman Khandual wrote:
>
>
> On 08/19/2020 11:17 AM, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to s
On 08/19/2020 11:17 AM, Alex Shi wrote:
> pageblock_flags is used as long, since every pageblock_flags is just 4
> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> flags. It woul
pageblock_flags is used as long, since every pageblock_flags is just 4
bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
flags. It would cause long waiting for sync.
If we could change the pageblock_flags
The kernel test bot reported[1] that using set_mask_bits on a u8 causes
the following issue on SuperH:
>> ERROR: modpost: "__cmpxchg_called_with_bad_pointer"
[drivers/phy/ti/phy-tusb1210.ko] undefined!
Add support for cmpxchg on u8 and u16 pointers.
[1] https://lore.kern
在 2020/8/17 下午5:58, Wei Yang 写道:
> On Sun, Aug 16, 2020 at 11:47:56AM +0800, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to s
On Sun, Aug 16, 2020 at 11:47:56AM +0800, Alex Shi wrote:
>pageblock_flags is used as long, since every pageblock_flags is just 4
>bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
>flags. It
在 2020/8/16 下午8:16, David Hildenbrand 写道:
> On 16.08.20 05:47, Alex Shi wrote:
>> pageblock_flags is used as long, since every pageblock_flags is just 4
>> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
>> that flag setting has to sync in cmpxc
6c1ba1c997653a4ff6885c81dc0ab Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Sat, 15 Aug 2020 22:54:17 +0800
Subject: [PATCH 1/2] mm/pageblock: mitigation cmpxchg false sharing in
pageblock flags
pageblock_flags is used as long, since every pageblock_flags is just 4
bits, 'long' size will include 8
On 16.08.20 05:47, Alex Shi wrote:
> pageblock_flags is used as long, since every pageblock_flags is just 4
> bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
> that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
> flags. It would cause
On Sun, Aug 16, 2020 at 11:47:56AM +0800, Alex Shi wrote:
> +++ b/mm/page_alloc.c
> @@ -467,6 +467,8 @@ static inline int pfn_to_bitidx(struct page *page,
> unsigned long pfn)
> return (pfn >> pageblock_order) * NR_PAGEBLOCK_BITS;
> }
>
> +#define BITS_PER_CHAR8
pageblock_flags is used as long, since every pageblock_flags is just 4
bits, 'long' size will include 8(32bit machine) or 16 pageblocks' flags,
that flag setting has to sync in cmpxchg with 7 or 15 other pageblock
flags. It would cause long waiting for sync.
If we could change the pageblock_flags
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
+0x2f4): undefined reference to
`__cmpxchg_called_with_bad_pointer'
>> hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on
; hppa-linux-ld: (.text+0x324): undefined reference to
`__cmpxchg_called_with_bad_pointer'
hppa-linux-ld: (.text+0x354): undefined reference to
`__cmpxchg_called_with_bad_pointer'
Add support for cmpxchg on u8 pointers.
[1] https://lore.kernel.org/patchwork/patch/1272617/#1468946
Reporte
1 - 100 of 1412 matches
Mail list logo
