* Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()
From: Waiman Long @ 2019-02-14 18:35 UTC (permalink / raw)
To: Will Deacon, Peter Zijlstra
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, H. Peter Anvin,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
linux-alpha, sparclinux, Thomas Gleixner, linuxppc-dev,
Andrew Morton, linux-arm-kernel
In-Reply-To: <20190214180239.GI2475@fuggles.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]
On 02/14/2019 01:02 PM, Will Deacon wrote:
> On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
>>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>>> it generate slightly better code.
>>>
>>> Before this patch, down_read_trylock:
>>>
>>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>>> 0x0000000000000005 <+5>: jmp 0x18 <down_read_trylock+24>
>>> 0x0000000000000007 <+7>: lea 0x1(%rdx),%rcx
>>> 0x000000000000000b <+11>: mov %rdx,%rax
>>> 0x000000000000000e <+14>: lock cmpxchg %rcx,(%rdi)
>>> 0x0000000000000013 <+19>: cmp %rax,%rdx
>>> 0x0000000000000016 <+22>: je 0x23 <down_read_trylock+35>
>>> 0x0000000000000018 <+24>: mov (%rdi),%rdx
>>> 0x000000000000001b <+27>: test %rdx,%rdx
>>> 0x000000000000001e <+30>: jns 0x7 <down_read_trylock+7>
>>> 0x0000000000000020 <+32>: xor %eax,%eax
>>> 0x0000000000000022 <+34>: retq
>>> 0x0000000000000023 <+35>: mov %gs:0x0,%rax
>>> 0x000000000000002c <+44>: or $0x3,%rax
>>> 0x0000000000000030 <+48>: mov %rax,0x20(%rdi)
>>> 0x0000000000000034 <+52>: mov $0x1,%eax
>>> 0x0000000000000039 <+57>: retq
>>>
>>> After patch, down_read_trylock:
>>>
>>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>>> 0x0000000000000005 <+5>: xor %eax,%eax
>>> 0x0000000000000007 <+7>: lea 0x1(%rax),%rdx
>>> 0x000000000000000b <+11>: lock cmpxchg %rdx,(%rdi)
>>> 0x0000000000000010 <+16>: jne 0x29 <down_read_trylock+41>
>>> 0x0000000000000012 <+18>: mov %gs:0x0,%rax
>>> 0x000000000000001b <+27>: or $0x3,%rax
>>> 0x000000000000001f <+31>: mov %rax,0x20(%rdi)
>>> 0x0000000000000023 <+35>: mov $0x1,%eax
>>> 0x0000000000000028 <+40>: retq
>>> 0x0000000000000029 <+41>: test %rax,%rax
>>> 0x000000000000002c <+44>: jns 0x7 <down_read_trylock+7>
>>> 0x000000000000002e <+46>: xor %eax,%eax
>>> 0x0000000000000030 <+48>: retq
>>>
>>> By using a rwsem microbenchmark, the down_read_trylock() rate (with a
>>> load of 10 to lengthen the lock critical section) on a x86-64 system
>>> before and after the patch were:
>>>
>>> Before Patch After Patch
>>> # of Threads rlock rlock
>>> ------------ ----- -----
>>> 1 14,496 14,716
>>> 2 8,644 8,453
>>> 4 6,799 6,983
>>> 8 5,664 7,190
>>>
>>> On a ARM64 system, the performance results were:
>>>
>>> Before Patch After Patch
>>> # of Threads rlock rlock
>>> ------------ ----- -----
>>> 1 23,676 24,488
>>> 2 7,697 9,502
>>> 4 4,945 3,440
>>> 8 2,641 1,603
>> Urgh, yes LL/SC is the obvious exception that can actually do better
>> here :/
>>
>> Will, what say you?
> What machine were these numbers generated on and is it using LL/SC or LSE
> atomics for arm64? If you stick the microbenchmark somewhere, I can go play
> with a broader variety of h/w.
>
> Will
The machine is a 2-socket Cavium ThunderX2 99xx system with 64 cores and
256 threads. I was just using threads from the first socket for this
test. The microbenchmark that I used is attached. I used the command
"./run-locktest -ltryrwsem -r100 -i-10 -c10 -n<threads>" to generate the
locking rates.
The lscpu flags were:
fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm
Cheers,
Longman
[-- Attachment #2: locktest.tar.gz --]
[-- Type: application/gzip, Size: 9620 bytes --]
^ permalink raw reply
* Re: Kernel panic when loading the IDE controller driver
From: Michal Suchánek @ 2019-02-14 18:14 UTC (permalink / raw)
To: sgosavi1; +Cc: linuxppc-dev
In-Reply-To: <1550132231035-0.post@n7.nabble.com>
On Thu, 14 Feb 2019 01:17:11 -0700 (MST)
sgosavi1 <Sachin.Gosavi@emerson.com> wrote:
> > Maybe look around
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
> > id=9a0e77f28b50128df0c9e26ae489e44e29a7270a
>
> >Also look at ide_platform.c. I imagine there must be some way to set it
> >up in your device tree.
>
> I have gone through this before and also tried the pata_platform driver but
> no success yet. I haven't found any example that passes the IO ports and IRQ
> information through the device tree to the driver code.
Hopefully there are examples of passing these values through ACPI.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()
From: Linus Torvalds @ 2019-02-14 18:09 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, Linux-sh list, Peter Zijlstra, linux-hexagon,
the arch/x86 maintainers, Will Deacon, Linux List Kernel Mailing,
Ingo Molnar, Borislav Petkov, H. Peter Anvin,
linux-alpha@vger.kernel.org, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-alpha@vger.kernel.org
In-Reply-To: <CAHk-=whKmuranma_HUOKBbDJHGmdWZr9MYW-+cmGzsOiJ2N1Sg@mail.gmail.com>
On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The arm64 numbers scaled horribly even before, and that's because
> there is too much ping-pong, and it's probably because there is no
> "stickiness" to the cacheline to the core, and thus adding the extra
> loop can make the ping-pong issue even worse because now there is more
> of it.
Actually, if it's using the ll/sc, then I don't see why arm64 should
even change. It doesn't really even change the pattern: the initial
load of the value is just replaced with a "ll" that gets a non-zero
value, and then we re-try without even doing the "sc" part.
End result: exact same "load once, then do ll/sc to update". Just
using a slightly different instruction pattern.
But maybe "ll" does something different to the cacheline than a regular "ld"?
Alternatively, the machine you used is using LSE, and the "swp" thing
has some horrid behavior when it fails.
So I take it back. I'm actually surprised that arm64 performs worse. I
don't think it should. But numbers walk, bullshit talks, and it
clearly does make for worse numbers on arm64.
Linus
^ permalink raw reply
* Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()
From: Will Deacon @ 2019-02-14 18:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, H. Peter Anvin,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
linux-alpha, sparclinux, Waiman Long, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <20190214103333.GH32494@hirez.programming.kicks-ass.net>
On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> > it generate slightly better code.
> >
> > Before this patch, down_read_trylock:
> >
> > 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
> > 0x0000000000000005 <+5>: jmp 0x18 <down_read_trylock+24>
> > 0x0000000000000007 <+7>: lea 0x1(%rdx),%rcx
> > 0x000000000000000b <+11>: mov %rdx,%rax
> > 0x000000000000000e <+14>: lock cmpxchg %rcx,(%rdi)
> > 0x0000000000000013 <+19>: cmp %rax,%rdx
> > 0x0000000000000016 <+22>: je 0x23 <down_read_trylock+35>
> > 0x0000000000000018 <+24>: mov (%rdi),%rdx
> > 0x000000000000001b <+27>: test %rdx,%rdx
> > 0x000000000000001e <+30>: jns 0x7 <down_read_trylock+7>
> > 0x0000000000000020 <+32>: xor %eax,%eax
> > 0x0000000000000022 <+34>: retq
> > 0x0000000000000023 <+35>: mov %gs:0x0,%rax
> > 0x000000000000002c <+44>: or $0x3,%rax
> > 0x0000000000000030 <+48>: mov %rax,0x20(%rdi)
> > 0x0000000000000034 <+52>: mov $0x1,%eax
> > 0x0000000000000039 <+57>: retq
> >
> > After patch, down_read_trylock:
> >
> > 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
> > 0x0000000000000005 <+5>: xor %eax,%eax
> > 0x0000000000000007 <+7>: lea 0x1(%rax),%rdx
> > 0x000000000000000b <+11>: lock cmpxchg %rdx,(%rdi)
> > 0x0000000000000010 <+16>: jne 0x29 <down_read_trylock+41>
> > 0x0000000000000012 <+18>: mov %gs:0x0,%rax
> > 0x000000000000001b <+27>: or $0x3,%rax
> > 0x000000000000001f <+31>: mov %rax,0x20(%rdi)
> > 0x0000000000000023 <+35>: mov $0x1,%eax
> > 0x0000000000000028 <+40>: retq
> > 0x0000000000000029 <+41>: test %rax,%rax
> > 0x000000000000002c <+44>: jns 0x7 <down_read_trylock+7>
> > 0x000000000000002e <+46>: xor %eax,%eax
> > 0x0000000000000030 <+48>: retq
> >
> > By using a rwsem microbenchmark, the down_read_trylock() rate (with a
> > load of 10 to lengthen the lock critical section) on a x86-64 system
> > before and after the patch were:
> >
> > Before Patch After Patch
> > # of Threads rlock rlock
> > ------------ ----- -----
> > 1 14,496 14,716
> > 2 8,644 8,453
> > 4 6,799 6,983
> > 8 5,664 7,190
> >
> > On a ARM64 system, the performance results were:
> >
> > Before Patch After Patch
> > # of Threads rlock rlock
> > ------------ ----- -----
> > 1 23,676 24,488
> > 2 7,697 9,502
> > 4 4,945 3,440
> > 8 2,641 1,603
>
> Urgh, yes LL/SC is the obvious exception that can actually do better
> here :/
>
> Will, what say you?
What machine were these numbers generated on and is it using LL/SC or LSE
atomics for arm64? If you stick the microbenchmark somewhere, I can go play
with a broader variety of h/w.
Will
^ permalink raw reply
* Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()
From: Linus Torvalds @ 2019-02-14 17:51 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, Linux-sh list, Peter Zijlstra, linux-hexagon,
the arch/x86 maintainers, Will Deacon, Linux List Kernel Mailing,
Ingo Molnar, Borislav Petkov, H. Peter Anvin,
linux-alpha@vger.kernel.org, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-alpha@vger.kernel.org
In-Reply-To: <9e01d4ef-56df-7af8-a0f5-b49644e298bf@redhat.com>
On Thu, Feb 14, 2019 at 6:53 AM Waiman Long <longman@redhat.com> wrote:
>
> The ARM64 result is what I would have expected given that the change was
> to optimize for the uncontended case. The x86-64 result is kind of an
> anomaly to me, but I haven't bothered to dig into that.
I would say that the ARM result is what I'd expect from something that
scales badly to begin with.
The x86-64 result is the expected one: yes, the cmpxchg is done one
extra time, but it results in fewer cache transitions (the cacheline
never goes into "shared" state), and cache transitions are what
matter.
The cost of re-doing the instruction should be low. The cacheline
ping-pong and the cache coherency messages is what hurts.
So I actually think both are very easily explained.
The x86-64 number improves, because there is less cache coherency traffic.
The arm64 numbers scaled horribly even before, and that's because
there is too much ping-pong, and it's probably because there is no
"stickiness" to the cacheline to the core, and thus adding the extra
loop can make the ping-pong issue even worse because now there is more
of it.
The cachelines not sticking at all to a core probably is good for
fairness issues (in particular, sticking *too* much can cause horrible
issues), but it's absolutely horrible if it means that you lose the
cacheline even before you get to complete the second cmpxchg.
Linus
^ permalink raw reply
* Re: Kernel panic when loading the IDE controller driver
From: Christophe Leroy @ 2019-02-14 17:54 UTC (permalink / raw)
To: sgosavi1, linuxppc-dev, Bartlomiej Zolnierkiewicz, linux-ide,
David S. Miller
In-Reply-To: <173559f3-7b2b-735b-acc7-66ccbdc7905d@c-s.fr>
Le 13/02/2019 à 16:27, Christophe Leroy a écrit :
>
>
> Le 13/02/2019 à 13:53, sgosavi1 a écrit :
>>> Why using 4.15.13 which is obsolete instead of using one of the Long
>>> Term Support versions which are still maintained, like 4.14 or 4.19 ?
>>> (see the complete list at https://www.kernel.org/category/releases.html)
>>
>> Well, when I started this task 4.15.13 was probably the latest stable
>> release and hence we decided to port this version. In the older
>> kernel, we
>> have the m8260_setup.c source file for our board where the function
>> "io_block_mapping" was used to configure the non-standard IO port address
>> starting at 0xe0000000 location. This address was passed as the base
>> address
>> followed by control address and IRQ number to the ide-core.ko module.
>> In the
>> new kernel we do not have an option to send these addresses and IRQ
>> numbers
>> as arguments to the driver. Instead the ide-generic.c source file in
>> the new
>> kernel uses the standard IO port values and IRQ values. I modified the
>> code
>> in the above file to used the addresses and IRQ number we used in the
>> past.
>> Also, added code in the "MMU_init" function call available under
>> arch/PowerPC/init_32.c to setup the IO port address range by adding the
>> "io_block_mapping" call and the required IO port address range.
>>
>> Is there anything else that needs to be added or how can we configure the
>> desired IO address range in the new kernel?
>>
>
> Maybe look around
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9a0e77f28b50128df0c9e26ae489e44e29a7270a
>
>
> Also look at ide_platform.c. I imagine there must be some way to set it
> up in your device tree.
>
> Maybe Bartlomiej Zolnierkiewicz can help ?
>
> Christophe
Le 14/02/2019 à 09:17, sgosavi1 a écrit :>> Maybe look around
>
> I have gone through this before and also tried the pata_platform
driver but
> no success yet. I haven't found any example that passes the IO ports
and IRQ
> information through the device tree to the driver code.
>
> Thanks,
> Sachin.
Maybe someone from the IDE SUBSYSTEM would be able to help better ?
Entire thread at
http://linuxppc.10917.n7.nabble.com/Kernel-panic-when-loading-the-IDE-controller-driver-td150020.html#none
Christophe
^ permalink raw reply
* Re: [PATCH 03/11] kernel/locks: consolidate RWSEM_GENERIC_* options
From: Waiman Long @ 2019-02-14 17:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linux-Arch, linux-s390, linux-kbuild, linux-xtensa,
Linux Kernel Mailing List, Masahiro Yamada, Geert Uytterhoeven,
linux-riscv, linuxppc-dev
In-Reply-To: <20190214170440.GB32441@lst.de>
On 02/14/2019 12:04 PM, Christoph Hellwig wrote:
> On Thu, Feb 14, 2019 at 10:26:52AM -0500, Waiman Long wrote:
>> Would you mind dropping just patch 3 from your series?
> Sure, we can just drop this patch.
Thanks,
Longman
^ permalink raw reply
* Re: [PATCH 01/11] powerpc: remove dead ifdefs in <asm/checksum.h>
From: Christoph Hellwig @ 2019-02-14 17:05 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-s390, linux-kbuild, linux-xtensa, linux-kernel,
Masahiro Yamada, linux-riscv, linuxppc-dev, Christoph Hellwig
In-Reply-To: <e7a2efe3-f56c-7dfd-6613-dc9229556673@c-s.fr>
On Thu, Feb 14, 2019 at 09:26:19AM +0100, Christophe Leroy wrote:
> Could you also remove the 'config GENERIC_CSUM' item in
> arch/powerpc/Kconfig ?
All the separate declarations go away later in this series.
^ permalink raw reply
* Re: [PATCH 03/11] kernel/locks: consolidate RWSEM_GENERIC_* options
From: Christoph Hellwig @ 2019-02-14 17:04 UTC (permalink / raw)
To: Waiman Long
Cc: Linux-Arch, linux-s390, linux-kbuild, linux-xtensa,
Linux Kernel Mailing List, Masahiro Yamada, Geert Uytterhoeven,
linux-riscv, linuxppc-dev, Christoph Hellwig
In-Reply-To: <d9aeeedd-ce72-f58f-d858-3e340c073414@redhat.com>
On Thu, Feb 14, 2019 at 10:26:52AM -0500, Waiman Long wrote:
> Would you mind dropping just patch 3 from your series?
Sure, we can just drop this patch.
^ permalink raw reply
* Re: [PATCH 15/19] KVM: PPC: Book3S HV: add get/set accessors for the source configuration
From: Cédric Le Goater @ 2019-02-14 16:50 UTC (permalink / raw)
To: David Gibson; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190208051543.GE2688@umbus.fritz.box>
On 2/8/19 6:15 AM, David Gibson wrote:
> On Thu, Feb 07, 2019 at 10:13:48AM +0100, Cédric Le Goater wrote:
>> On 2/7/19 3:48 AM, David Gibson wrote:
>>> On Wed, Feb 06, 2019 at 08:07:36AM +0100, Cédric Le Goater wrote:
>>>> On 2/6/19 2:24 AM, David Gibson wrote:
>>>>> On Wed, Feb 06, 2019 at 12:23:29PM +1100, David Gibson wrote:
>>>>>> On Tue, Feb 05, 2019 at 02:03:11PM +0100, Cédric Le Goater wrote:
>>>>>>> On 2/5/19 6:32 AM, David Gibson wrote:
>>>>>>>> On Mon, Feb 04, 2019 at 05:07:28PM +0100, Cédric Le Goater wrote:
>>>>>>>>> On 2/4/19 6:21 AM, David Gibson wrote:
>>>>>>>>>> On Mon, Jan 07, 2019 at 07:43:27PM +0100, Cédric Le Goater wrote:
>>>>>>>>>>> Theses are use to capure the XIVE EAS table of the KVM device, the
>>>>>>>>>>> configuration of the source targets.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>>>>>>>>>> ---
>>>>>>>>>>> arch/powerpc/include/uapi/asm/kvm.h | 11 ++++
>>>>>>>>>>> arch/powerpc/kvm/book3s_xive_native.c | 87 +++++++++++++++++++++++++++
>>>>>>>>>>> 2 files changed, 98 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
>>>>>>>>>>> index 1a8740629acf..faf024f39858 100644
>>>>>>>>>>> --- a/arch/powerpc/include/uapi/asm/kvm.h
>>>>>>>>>>> +++ b/arch/powerpc/include/uapi/asm/kvm.h
>>>>>>>>>>> @@ -683,9 +683,20 @@ struct kvm_ppc_cpu_char {
>>>>>>>>>>> #define KVM_DEV_XIVE_SAVE_EQ_PAGES 4
>>>>>>>>>>> #define KVM_DEV_XIVE_GRP_SOURCES 2 /* 64-bit source attributes */
>>>>>>>>>>> #define KVM_DEV_XIVE_GRP_SYNC 3 /* 64-bit source attributes */
>>>>>>>>>>> +#define KVM_DEV_XIVE_GRP_EAS 4 /* 64-bit eas attributes */
>>>>>>>>>>>
>>>>>>>>>>> /* Layout of 64-bit XIVE source attribute values */
>>>>>>>>>>> #define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
>>>>>>>>>>> #define KVM_XIVE_LEVEL_ASSERTED (1ULL << 1)
>>>>>>>>>>>
>>>>>>>>>>> +/* Layout of 64-bit eas attribute values */
>>>>>>>>>>> +#define KVM_XIVE_EAS_PRIORITY_SHIFT 0
>>>>>>>>>>> +#define KVM_XIVE_EAS_PRIORITY_MASK 0x7
>>>>>>>>>>> +#define KVM_XIVE_EAS_SERVER_SHIFT 3
>>>>>>>>>>> +#define KVM_XIVE_EAS_SERVER_MASK 0xfffffff8ULL
>>>>>>>>>>> +#define KVM_XIVE_EAS_MASK_SHIFT 32
>>>>>>>>>>> +#define KVM_XIVE_EAS_MASK_MASK 0x100000000ULL
>>>>>>>>>>> +#define KVM_XIVE_EAS_EISN_SHIFT 33
>>>>>>>>>>> +#define KVM_XIVE_EAS_EISN_MASK 0xfffffffe00000000ULL
>>>>>>>>>>> +
>>>>>>>>>>> #endif /* __LINUX_KVM_POWERPC_H */
>>>>>>>>>>> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
>>>>>>>>>>> index f2de1bcf3b35..0468b605baa7 100644
>>>>>>>>>>> --- a/arch/powerpc/kvm/book3s_xive_native.c
>>>>>>>>>>> +++ b/arch/powerpc/kvm/book3s_xive_native.c
>>>>>>>>>>> @@ -525,6 +525,88 @@ static int kvmppc_xive_native_sync(struct kvmppc_xive *xive, long irq, u64 addr)
>>>>>>>>>>> return 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> +static int kvmppc_xive_native_set_eas(struct kvmppc_xive *xive, long irq,
>>>>>>>>>>> + u64 addr)
>>>>>>>>>>
>>>>>>>>>> I'd prefer to avoid the name "EAS" here. IIUC these aren't "raw" EAS
>>>>>>>>>> values, but rather essentially the "source config" in the terminology
>>>>>>>>>> of the PAPR hcalls. Which, yes, is basically implemented by setting
>>>>>>>>>> the EAS, but since it's the PAPR architected state that we need to
>>>>>>>>>> preserve across migration, I'd prefer to stick as close as we can to
>>>>>>>>>> the PAPR terminology.
>>>>>>>>>
>>>>>>>>> But we don't have an equivalent name in the PAPR specs for the tuple
>>>>>>>>> (prio, server). We could use the generic 'target' name may be ? even
>>>>>>>>> if this is usually referring to a CPU number.
>>>>>>>>
>>>>>>>> Um.. what? That's about terminology for one of the fields in this
>>>>>>>> thing, not about the name for the thing itself.
>>>>>>>>
>>>>>>>>> Or, IVE (Interrupt Vector Entry) ? which makes some sense.
>>>>>>>>> This is was the former name in HW. I think we recycle it for KVM.
>>>>>>>>
>>>>>>>> That's a terrible idea, which will make a confusing situation even
>>>>>>>> more confusing.
>>>>>>>
>>>>>>> Let's use SOURCE_CONFIG and QUEUE_CONFIG. The KVM ioctls are very
>>>>>>> similar to the hcalls anyhow.
>>>>>>
>>>>>> Yes, I think that's a good idea.
>>>>>
>>>>> Actually... AIUI the SET_CONFIG hcalls shouldn't be a fast path.
>>>>
>>>> No indeed. I have move them to standard hcalls in the current version.
>>>>
>>>>> Can
>>>>> we simplify things further by removing the hcall implementation from
>>>>> the kernel entirely, and have qemu implement them by basically just
>>>>> forwarding them to the appropriate SET_CONFIG ioctl()?
>>>>
>>>> Yes. I think we could.
>>>
>>> Great!
>>>
>>>> The hcalls H_INT_SET_SOURCE_CONFIG and H_INT_SET_QUEUE_CONFIG and
>>>> the KVM ioctls to set the EQ and the SOURCE configuration have a
>>>> lot in common. I need to look at how we can plug the KVM ioctl in
>>>> the hcalls under QEMU.
>>>>
>>>> We will have to convert the returned error to respect the PAPR
>>>> specs or have the ioctls return H_* errors.
>>>
>>> I don't think returning H_* values from a kernel call is a good idea.
>>> Converting errors is kinda ugly, but I still think it's the better
>>> option. Note that we already have something like this for the HPT
>>> resizing hcalls.
>>
>> ok.
>>
>>>> Let's dig that idea. If we choose that path, QEMU will have an
>>>> up-to-date EAT and so we won't need to synchronize its state anymore
>>>> for migration.
>>>
>>> I guess so, though I don't see that as essential.
>>>
>>>> H_INT_GET_SOURCE_CONFIG can be implemented in QEMU without any KVM
>>>> ioctl.
>>>>
>>>> H_INT_GET_QUEUE_INFO could be implemented in QEMU. I need to check
>>>> how we return the address of the END ESB in sPAPR. We haven't paid
>>>> much attention to these pages because they are not used under Linux
>>>> and today the address is returned by OPAL.
>>>>
>>>> H_INT_GET_QUEUE_CONFIG is a little more problematic because we need
>>>> to query into the XIVE HW the EQ index and toggle bit. OPAL support
>>>> is required for that. But we could reduce the KVM support to the
>>>> ioctl querying these EQ information.
>>>
>>> Right, and we'd need an ioctl() like that for migration anyway, yes?
>>
>> Yes. it is the same need.
>>
>>>> H_INT_ESB could be entirely done under QEMU.
>>>
>>> This one can actually happen on fairly hot paths, so I think doing
>>> that in qemu probably isn't a good idea.
>>
>> I agree It would nice to have some performance.
>>
>> This hcall is used when LSIs are involved, which is not really a common
>> configuration. There are no OPAL calls involved. And we are duplicating
>> code at the KVM level to retrigger the interrupt when the level is still
>> asserted.
>>
>> I will benchmark the two options before making a choice.
>
> Ok.
Here are some iperf results for a 4 vCPUs guest running a 5.0.0 kernel
on a small initrd image. I didn't do any kind of tuning like CPU pinning.
So these are really rough figures :
kernel irqchip OFF ON ON (*)
rtl8139 (LSI) 1.19 1.24 1.23 Gbits/sec
VIRTIO 31.80 42.30 -- Gbits/sec
There is not much benefit in handling the H_INT_ESB hcall under KVM it seems.
I think we can leave it under QEMU.
C.
^ permalink raw reply
* Re: [PATCH V2 00/10] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
From: Paolo Bonzini @ 2019-02-14 16:40 UTC (permalink / raw)
To: lantianyu1986
Cc: kvm, rkrcmar, will.deacon, christoffer.dall, hpa, kys, kvmarm,
sashal, sthemmin, x86, linux, michael.h.kelley, mingo,
catalin.marinas, jhogan, linux-mips, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
paul.burton, devel, vkuznets, linuxppc-dev
In-Reply-To: <20190202013825.51261-1-Tianyu.Lan@microsoft.com>
On 02/02/19 02:38, lantianyu1986@gmail.com wrote:
> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
>
> This patchset is to introduce hv ept tlb range list flush function
> support in the KVM MMU component. Flushing ept tlbs of several address
> range can be done via single hypercall and new list flush function is
> used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset
> also adds more hv ept tlb range flush support in more KVM MMU function.
>
> Change since v1:
> 1) Make flush list as a hlist instead of list in order to
> keep struct kvm_mmu_page size.
> 2) Add last_level flag in the struct kvm_mmu_page instead
> of spte pointer
> 3) Move tlb flush from kvm_mmu_notifier_clear_flush_young() to kvm_age_hva()
> 4) Use range flush in the kvm_vm_ioctl_get/clear_dirty_log()
Looks good except for the confusion on sp->last_level (which was mostly
mine---sorry about that). I think it can still make 5.1.
However, note that I've never received "KVM/MMU: Use tlb range flush in
the kvm_age_hva()".
Paolo
^ permalink raw reply
* Re: [PATCH V2 3/10] KVM/MMU: Add last_level in the struct mmu_spte_page
From: Paolo Bonzini @ 2019-02-14 16:32 UTC (permalink / raw)
To: lantianyu1986
Cc: kvm, rkrcmar, catalin.marinas, will.deacon, christoffer.dall, hpa,
kys, kvmarm, x86, linux, michael.h.kelley, mingo, jhogan,
linux-mips, Lan Tianyu, marc.zyngier, kvm-ppc, bp, tglx,
linux-arm-kernel, linux-kernel, ralf, paul.burton, vkuznets,
linuxppc-dev
In-Reply-To: <20190202013825.51261-4-Tianyu.Lan@microsoft.com>
On 02/02/19 02:38, lantianyu1986@gmail.com wrote:
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ce770b446238..70cafd3f95ab 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2918,6 +2918,9 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
>
> if (level > PT_PAGE_TABLE_LEVEL)
> spte |= PT_PAGE_SIZE_MASK;
> +
> + sp->last_level = is_last_spte(spte, level);
Wait, I wasn't thinking straight. If a struct kvm_mmu_page exists, it
is never the last level. Page table entries for the last level do not
have a struct kvm_mmu_page.
Therefore you don't need the flag after all. I suspect your
calculations in patch 2 are off by one, and you actually need
hlist_for_each_entry(sp, range->flush_list, flush_link) {
int pages = KVM_PAGES_PER_HPAGE(sp->role.level + 1);
...
}
For example, if sp->role.level is 1 then the struct kvm_mmu_page is for
a page containing PTEs and covers an area of 2 MiB.
Thanks,
Paolo
> if (tdp_enabled)
> spte |= kvm_x86_ops->get_mt_mask(vcpu, gfn,
> kvm_is_mmio_pfn(pfn));
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
From: Jan Kara @ 2019-02-14 16:31 UTC (permalink / raw)
To: Michael Ellerman
Cc: erhard_f, jack, linuxppc-dev, linux-kernel, linux-mm,
aneesh.kumar
In-Reply-To: <20190214062339.7139-1-mpe@ellerman.id.au>
On Thu 14-02-19 17:23:39, Michael Ellerman wrote:
> In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> rather than just checking that the value is non-zero, e.g.:
>
> static inline int pgd_present(pgd_t pgd)
> {
> - return !pgd_none(pgd);
> + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> Unfortunately this is broken on big endian, as the result of the
> bitwise && is truncated to int, which is always zero because
> _PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and
> pud_present() are always false at compile time, and the compiler
> elides the subsequent code.
>
> Remarkably with that bug present we are still able to boot and run
> with few noticeable effects. However under some work loads we are able
> to trigger a warning in the ext4 code:
Wow, good catch. I wouldn't believe there are so few bad effects from
such a major breakage! :)
Honza
>
> WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0
> CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1
> ...
> NIP .ext4_set_page_dirty+0x70/0xb0
> LR .set_page_dirty+0xa0/0x150
> Call Trace:
> .set_page_dirty+0xa0/0x150
> .unmap_page_range+0xbf0/0xe10
> .unmap_vmas+0x84/0x130
> .unmap_region+0xe8/0x190
> .__do_munmap+0x2f0/0x510
> .__vm_munmap+0x80/0x110
> .__se_sys_munmap+0x14/0x30
> system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debugging.
>
> Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit")
> Cc: stable@vger.kernel.org # v4.20+
> Reported-by: Erhard F. <erhard_f@mailbox.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index c9bfe526ca9d..d8c8d7c9df15 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -904,7 +904,7 @@ static inline int pud_none(pud_t pud)
>
> static inline int pud_present(pud_t pud)
> {
> - return (pud_raw(pud) & cpu_to_be64(_PAGE_PRESENT));
> + return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> extern struct page *pud_page(pud_t pud);
> @@ -951,7 +951,7 @@ static inline int pgd_none(pgd_t pgd)
>
> static inline int pgd_present(pgd_t pgd)
> {
> - return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> + return !!(pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> static inline pte_t pgd_pte(pgd_t pgd)
> --
> 2.20.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH V2 3/10] KVM/MMU: Add last_level in the struct mmu_spte_page
From: Paolo Bonzini @ 2019-02-14 16:12 UTC (permalink / raw)
To: lantianyu1986
Cc: kvm, rkrcmar, catalin.marinas, will.deacon, christoffer.dall, hpa,
kys, kvmarm, x86, linux, michael.h.kelley, mingo, jhogan,
linux-mips, Lan Tianyu, marc.zyngier, kvm-ppc, bp, tglx,
linux-arm-kernel, linux-kernel, ralf, paul.burton, vkuznets,
linuxppc-dev
In-Reply-To: <20190202013825.51261-4-Tianyu.Lan@microsoft.com>
On 02/02/19 02:38, lantianyu1986@gmail.com wrote:
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ce770b446238..70cafd3f95ab 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -2918,6 +2918,9 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
>
> if (level > PT_PAGE_TABLE_LEVEL)
> spte |= PT_PAGE_SIZE_MASK;
> +
> + sp->last_level = is_last_spte(spte, level);
sp->last_level is always true here.
Paolo
> if (tdp_enabled)
> spte |= kvm_x86_ops->get_mt_mask(vcpu, gfn,
> kvm_is_mmio_pfn(pfn));
^ permalink raw reply
* [PATCH v04] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update
From: Michael Bringmann @ 2019-02-14 15:56 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Cc: Rob Herring, Srikar Dronamraju, Kees Cook, Nicholas Piggin,
Al Viro, Michael Bringmann, Juliet Kim, Paul Mackerras,
Tyrel Datwyler, Nathan Lynch, Oliver O'Halloran,
Thomas Falcon, Guenter Roeck, Corentin Labbe
To: linuxppc-dev@lists.ozlabs.org
To: linux-kernel@vger.kernel.org
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Paul Mackerras <paulus@samba.org>
Michael Ellerman <mpe@ellerman.id.au>
Nathan Lynch <nathanl@linux.vnet.ibm.com>
Corentin Labbe <clabbe@baylibre.com>
Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Guenter Roeck <linux@roeck-us.net>
Michael Bringmann <mwb@linux.vnet.ibm.com>
"Oliver O'Halloran" <oohall@gmail.com>
Russell Currey <ruscur@russell.cc>
Haren Myneni <haren@us.ibm.com>
Al Viro <viro@zeniv.linux.org.uk>
Kees Cook <keescook@chromium.org>
Nicholas Piggin <npiggin@gmail.com>
Rob Herring <robh@kernel.org>
Juliet Kim <minkim@us.ibm.com>
Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: 2018-11-05 16:14:12 -0600
Subject: [PATCH v04] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update
On pseries systems, performing changes to a partition's affinity
can result in altering the nodes a CPU is assigned to the
current system. For example, some systems are subject to resource
balancing operations by the operator or control software. In such
environments, system CPUs may be in node 1 and 3 at boot, and be
moved to nodes 2, 3, and 5, for better performance.
The current implementation attempts to recognize such changes within
the powerpc-specific version of arch_update_cpu_topology to modify a
range of system data structures directly. However, some scheduler
data structures may be inaccessible, or the timing of a node change
may still lead to corruption or error in other modules (e.g. user
space) which do not receive notification of these changes.
This patch modifies the PRRN/VPHN topology update worker function to
recognize an affinity change for a CPU, and to perform a full DLPAR
remove and add of the CPU instead of dynamically changing its node
to resolve this issue.
[Based upon patch submission:
Subject: [PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date: Tue Oct 30 05:43:36 AEDT 2018
]
[Replace patch submission:
Subject: [PATCH] powerpc/topology: Update numa mask when cpu node mapping changes
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Date: Wed Oct 10 15:24:46 AEDT 2018
]
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
---
Changes in v04:
-- Revise tests in topology_timer_fn to check vphn_enabled before prrn_enabled
-- Remove unnecessary changes to numa_update_cpu_topology
Changes in v03:
-- Fixed under-scheduling of topo updates.
Changes in v02:
-- Reuse more of the previous implementation to reduce patch size
-- Replace former calls to numa_update_cpu_topology(false) by
topology_schedule_update
-- Make sure that we report topology changes back through
arch_update_cpu_topology
-- Fix problem observed in powerpc next kernel with updating
cpu_associativity_changes_mask in timer_topology_fn when both
prrn_enabled and vphn_enabled, and many extra CPUs are possible,
but not installed.
-- Fix problem with updating cpu_associativity_changes_mask when
VPHN associativity information does not arrive until after first
call to update topology occurs.
---
arch/powerpc/include/asm/topology.h | 7 +----
arch/powerpc/kernel/rtasd.c | 2 +
arch/powerpc/mm/numa.c | 47 +++++++++++++++++++++++------------
3 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index f85e2b01c3df..79505c371fd5 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -42,7 +42,7 @@ extern void __init dump_numa_cpu_topology(void);
extern int sysfs_add_device_to_node(struct device *dev, int nid);
extern void sysfs_remove_device_from_node(struct device *dev, int nid);
-extern int numa_update_cpu_topology(bool cpus_locked);
+extern void topology_schedule_update(void);
static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node)
{
@@ -77,10 +77,7 @@ static inline void sysfs_remove_device_from_node(struct device *dev,
{
}
-static inline int numa_update_cpu_topology(bool cpus_locked)
-{
- return 0;
-}
+static inline void topology_schedule_update(void) {}
static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) {}
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 8a1746d755c9..b1828de7ab78 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -285,7 +285,7 @@ static void handle_prrn_event(s32 scope)
* the RTAS event.
*/
pseries_devicetree_update(-scope);
- numa_update_cpu_topology(false);
+ topology_schedule_update();
}
static void handle_rtas_event(const struct rtas_error_log *log)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index b5d1c45c1475..eb63479f09d7 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1077,6 +1077,8 @@ static int prrn_enabled;
static void reset_topology_timer(void);
static int topology_timer_secs = 1;
static int topology_inited;
+static int topology_update_in_progress;
+static int topology_changed;
/*
* Change polling interval for associativity changes.
@@ -1297,9 +1299,9 @@ static int update_lookup_table(void *data)
* Update the node maps and sysfs entries for each cpu whose home node
* has changed. Returns 1 when the topology has changed, and 0 otherwise.
*
- * cpus_locked says whether we already hold cpu_hotplug_lock.
+ * readd_cpus: Also readd any CPUs that have changed affinity
*/
-int numa_update_cpu_topology(bool cpus_locked)
+static int numa_update_cpu_topology(bool readd_cpus)
{
unsigned int cpu, sibling, changed = 0;
struct topology_update_data *updates, *ud;
@@ -1307,7 +1309,8 @@ int numa_update_cpu_topology(bool cpus_locked)
struct device *dev;
int weight, new_nid, i = 0;
- if (!prrn_enabled && !vphn_enabled && topology_inited)
+ if ((!prrn_enabled && !vphn_enabled && topology_inited) ||
+ topology_update_in_progress)
return 0;
weight = cpumask_weight(&cpu_associativity_changes_mask);
@@ -1318,6 +1321,8 @@ int numa_update_cpu_topology(bool cpus_locked)
if (!updates)
return 0;
+ topology_update_in_progress = 1;
+
cpumask_clear(&updated_cpus);
for_each_cpu(cpu, &cpu_associativity_changes_mask) {
@@ -1339,16 +1344,21 @@ int numa_update_cpu_topology(bool cpus_locked)
new_nid = find_and_online_cpu_nid(cpu);
- if (new_nid == numa_cpu_lookup_table[cpu]) {
+ if ((new_nid == numa_cpu_lookup_table[cpu]) ||
+ !cpu_present(cpu)) {
cpumask_andnot(&cpu_associativity_changes_mask,
&cpu_associativity_changes_mask,
cpu_sibling_mask(cpu));
- dbg("Assoc chg gives same node %d for cpu%d\n",
+ if (cpu_present(cpu))
+ dbg("Assoc chg gives same node %d for cpu%d\n",
new_nid, cpu);
cpu = cpu_last_thread_sibling(cpu);
continue;
}
+ if (readd_cpus)
+ dlpar_cpu_readd(cpu);
+
for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
ud = &updates[i++];
ud->next = &updates[i];
@@ -1390,7 +1400,7 @@ int numa_update_cpu_topology(bool cpus_locked)
if (!cpumask_weight(&updated_cpus))
goto out;
- if (cpus_locked)
+ if (!readd_cpus)
stop_machine_cpuslocked(update_cpu_topology, &updates[0],
&updated_cpus);
else
@@ -1401,9 +1411,9 @@ int numa_update_cpu_topology(bool cpus_locked)
* offline CPUs. It is best to perform this update from the stop-
* machine context.
*/
- if (cpus_locked)
+ if (!readd_cpus)
stop_machine_cpuslocked(update_lookup_table, &updates[0],
- cpumask_of(raw_smp_processor_id()));
+ cpumask_of(raw_smp_processor_id()));
else
stop_machine(update_lookup_table, &updates[0],
cpumask_of(raw_smp_processor_id()));
@@ -1420,35 +1430,40 @@ int numa_update_cpu_topology(bool cpus_locked)
}
out:
+ topology_update_in_progress = 0;
kfree(updates);
return changed;
}
int arch_update_cpu_topology(void)
{
- return numa_update_cpu_topology(true);
+ return numa_update_cpu_topology(false);
}
static void topology_work_fn(struct work_struct *work)
{
- rebuild_sched_domains();
+ lock_device_hotplug();
+ if (numa_update_cpu_topology(true))
+ rebuild_sched_domains();
+ unlock_device_hotplug();
}
static DECLARE_WORK(topology_work, topology_work_fn);
-static void topology_schedule_update(void)
+void topology_schedule_update(void)
{
- schedule_work(&topology_work);
+ if (!topology_update_in_progress)
+ schedule_work(&topology_work);
}
static void topology_timer_fn(struct timer_list *unused)
{
- if (prrn_enabled && cpumask_weight(&cpu_associativity_changes_mask))
- topology_schedule_update();
- else if (vphn_enabled) {
+ if (vphn_enabled) {
if (update_cpu_associativity_changes_mask() > 0)
topology_schedule_update();
reset_topology_timer();
}
+ else if (prrn_enabled && cpumask_weight(&cpu_associativity_changes_mask))
+ topology_schedule_update();
}
static struct timer_list topology_timer;
@@ -1553,7 +1568,7 @@ void __init shared_proc_topology_init(void)
if (lppaca_shared_proc(get_lppaca())) {
bitmap_fill(cpumask_bits(&cpu_associativity_changes_mask),
nr_cpumask_bits);
- numa_update_cpu_topology(false);
+ topology_schedule_update();
}
}
^ permalink raw reply related
* Re: [PATCH 03/11] kernel/locks: consolidate RWSEM_GENERIC_* options
From: Waiman Long @ 2019-02-14 15:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linux-Arch, linux-s390, linux-kbuild, linux-xtensa,
Linux Kernel Mailing List, Masahiro Yamada, Geert Uytterhoeven,
linux-riscv, linuxppc-dev
In-Reply-To: <CAMuHMdW4C1McxL-e7ZSiSOiiE5D=xbBK8FZOwuJ1w0kK3CR1Hg@mail.gmail.com>
On 02/14/2019 05:52 AM, Geert Uytterhoeven wrote:
> On Thu, Feb 14, 2019 at 12:08 AM Christoph Hellwig <hch@lst.de> wrote:
>> Introduce one central definition of RWSEM_XCHGADD_ALGORITHM and
>> RWSEM_GENERIC_SPINLOCK in kernel/Kconfig.locks and let architectures
>> select RWSEM_XCHGADD_ALGORITHM if they want it, otherwise default to
>> the spinlock version.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Note that this conflicts with "[PATCH v4 2/3] locking/rwsem: Remove
> rwsem-spinlock.c & use rwsem-xadd.c for all archs"
> https://lore.kernel.org/lkml/1550095217-12047-3-git-send-email-longman@redhat.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
Christoph,
Would you mind dropping just patch 3 from your series?
Thanks,
Longman
^ permalink raw reply
* Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
From: Waiman Long @ 2019-02-14 15:22 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: linux-arch, linux-xtensa, the arch/x86 maintainers, linux-ia64,
Tim Chen, Arnd Bergmann, Linux-sh list, Peter Zijlstra,
linux-hexagon, linuxppc-dev, Will Deacon,
Linux List Kernel Mailing, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
Linus Torvalds, Andrew Morton, linux-arm-kernel
In-Reply-To: <20190214132352.wm26r5g632swp34n@linux-r8p5>
On 02/14/2019 08:23 AM, Davidlohr Bueso wrote:
> On Fri, 08 Feb 2019, Waiman Long wrote:
>> I am planning to run more performance test and post the data sometimes
>> next week. Davidlohr is also going to run some of his rwsem performance
>> test on this patchset.
>
> So I ran this series on a 40-core IB 2 socket with various worklods in
> mmtests. Below are some of the interesting ones; full numbers and curves
> at https://linux-scalability.org/rwsem-reader-spinner/
>
> All workloads are with increasing number of threads.
>
> -- pagefault timings: pft is an artificial pf benchmark (thus reader
> stress).
> metric is faults/cpu and faults/sec
> v5.0-rc6 v5.0-rc6
> dirty
> Hmean faults/cpu-1 624224.9815 ( 0.00%) 618847.5201 * -0.86%*
> Hmean faults/cpu-4 539550.3509 ( 0.00%) 547407.5738 * 1.46%*
> Hmean faults/cpu-7 401470.3461 ( 0.00%) 381157.9830 * -5.06%*
> Hmean faults/cpu-12 267617.0353 ( 0.00%) 271098.5441 * 1.30%*
> Hmean faults/cpu-21 176194.4641 ( 0.00%) 175151.3256 * -0.59%*
> Hmean faults/cpu-30 119927.3862 ( 0.00%) 120610.1348 * 0.57%*
> Hmean faults/cpu-40 91203.6820 ( 0.00%) 91832.7489 * 0.69%*
> Hmean faults/sec-1 623292.3467 ( 0.00%) 617992.0795 * -0.85%*
> Hmean faults/sec-4 2113364.6898 ( 0.00%) 2140254.8238 * 1.27%*
> Hmean faults/sec-7 2557378.4385 ( 0.00%) 2450945.7060 * -4.16%*
> Hmean faults/sec-12 2696509.8975 ( 0.00%) 2747968.9819 * 1.91%*
> Hmean faults/sec-21 2902892.5639 ( 0.00%) 2905923.3881 * 0.10%*
> Hmean faults/sec-30 2956696.5793 ( 0.00%) 2990583.5147 * 1.15%*
> Hmean faults/sec-40 3422806.4806 ( 0.00%) 3352970.3082 * -2.04%*
> Stddev faults/cpu-1 2949.5159 ( 0.00%) 2802.2712 ( 4.99%)
> Stddev faults/cpu-4 24165.9454 ( 0.00%) 15841.1232 ( 34.45%)
> Stddev faults/cpu-7 20914.8351 ( 0.00%) 22744.3294 ( -8.75%)
> Stddev faults/cpu-12 11274.3490 ( 0.00%) 14733.3152 ( -30.68%)
> Stddev faults/cpu-21 2500.1950 ( 0.00%) 2200.9518 ( 11.97%)
> Stddev faults/cpu-30 1599.5346 ( 0.00%) 1414.0339 ( 11.60%)
> Stddev faults/cpu-40 1473.0181 ( 0.00%) 3004.1209 (-103.94%)
> Stddev faults/sec-1 2655.2581 ( 0.00%) 2405.1625 ( 9.42%)
> Stddev faults/sec-4 84042.7234 ( 0.00%) 57996.7158 ( 30.99%)
> Stddev faults/sec-7 123656.7901 ( 0.00%) 135591.1087 ( -9.65%)
> Stddev faults/sec-12 97135.6091 ( 0.00%) 127054.4926 ( -30.80%)
> Stddev faults/sec-21 69564.6264 ( 0.00%) 65922.6381 ( 5.24%)
> Stddev faults/sec-30 51524.4027 ( 0.00%) 56109.4159 ( -8.90%)
> Stddev faults/sec-40 101927.5280 ( 0.00%) 160117.0093 ( -57.09%)
>
> With the exception of the hicup at 7 threads, things are pretty much in
> the noise region for both metrics.
>
> -- git checkout
>
> First metric is total runtime for runs with incremental threads.
>
> v5.0-rc6 v5.0-rc6
> dirty
> User 218.95 219.07
> System 149.29 146.82
> Elapsed 1574.10 1427.08
>
> In this case there's a non trivial improvement (11%) in overall
> elapsed time.
>
> -- reaim (which is always succeptible to rwsem changes for both
> mmap_sem and
> i_mmap)
> v5.0-rc6 v5.0-rc6
> dirty
> Hmean compute-1 6674.01 ( 0.00%) 6544.28 * -1.94%*
> Hmean compute-21 85294.91 ( 0.00%) 85524.20 * 0.27%*
> Hmean compute-41 149674.70 ( 0.00%) 149494.58 * -0.12%*
> Hmean compute-61 177721.15 ( 0.00%) 170507.38 * -4.06%*
> Hmean compute-81 181531.07 ( 0.00%) 180463.24 * -0.59%*
> Hmean compute-101 189024.09 ( 0.00%) 187288.86 * -0.92%*
> Hmean compute-121 200673.24 ( 0.00%) 195327.65 * -2.66%*
> Hmean compute-141 213082.29 ( 0.00%) 211290.80 * -0.84%*
> Hmean compute-161 207764.06 ( 0.00%) 204626.68 * -1.51%*
>
> The 'compute' workload overall takes a small hit.
>
> Hmean new_dbase-1 60.48 ( 0.00%) 60.63 * 0.25%*
> Hmean new_dbase-21 6590.49 ( 0.00%) 6671.81 * 1.23%*
> Hmean new_dbase-41 14202.91 ( 0.00%) 14470.59 * 1.88%*
> Hmean new_dbase-61 21207.24 ( 0.00%) 21067.40 * -0.66%*
> Hmean new_dbase-81 25542.40 ( 0.00%) 25542.40 * 0.00%*
> Hmean new_dbase-101 30165.28 ( 0.00%) 30046.21 * -0.39%*
> Hmean new_dbase-121 33638.33 ( 0.00%) 33219.90 * -1.24%*
> Hmean new_dbase-141 36723.70 ( 0.00%) 37504.52 * 2.13%*
> Hmean new_dbase-161 42242.51 ( 0.00%) 42117.34 * -0.30%*
> Hmean shared-1 76.54 ( 0.00%) 76.09 * -0.59%*
> Hmean shared-21 7535.51 ( 0.00%) 5518.75 * -26.76%*
> Hmean shared-41 17207.81 ( 0.00%) 14651.94 * -14.85%*
> Hmean shared-61 20716.98 ( 0.00%) 18667.52 * -9.89%*
> Hmean shared-81 27603.83 ( 0.00%) 23466.45 * -14.99%*
> Hmean shared-101 26008.59 ( 0.00%) 29536.96 * 13.57%*
> Hmean shared-121 28354.76 ( 0.00%) 43139.39 * 52.14%*
> Hmean shared-141 38509.25 ( 0.00%) 41619.35 * 8.08%*
> Hmean shared-161 40496.07 ( 0.00%) 44303.46 * 9.40%*
>
> Overall there is a small hit (in the noise level but consistent
> throughout
> many workloads), except git-checkout which does quite well.
>
> Thanks,
> Davidlohr
Thanks for running the patch through your performance tests.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v3 2/2] locking/rwsem: Optimize down_read_trylock()
From: Waiman Long @ 2019-02-14 14:53 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, Will Deacon,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <20190214103333.GH32494@hirez.programming.kicks-ass.net>
On 02/14/2019 05:33 AM, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>> it generate slightly better code.
>>
>> Before this patch, down_read_trylock:
>>
>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>> 0x0000000000000005 <+5>: jmp 0x18 <down_read_trylock+24>
>> 0x0000000000000007 <+7>: lea 0x1(%rdx),%rcx
>> 0x000000000000000b <+11>: mov %rdx,%rax
>> 0x000000000000000e <+14>: lock cmpxchg %rcx,(%rdi)
>> 0x0000000000000013 <+19>: cmp %rax,%rdx
>> 0x0000000000000016 <+22>: je 0x23 <down_read_trylock+35>
>> 0x0000000000000018 <+24>: mov (%rdi),%rdx
>> 0x000000000000001b <+27>: test %rdx,%rdx
>> 0x000000000000001e <+30>: jns 0x7 <down_read_trylock+7>
>> 0x0000000000000020 <+32>: xor %eax,%eax
>> 0x0000000000000022 <+34>: retq
>> 0x0000000000000023 <+35>: mov %gs:0x0,%rax
>> 0x000000000000002c <+44>: or $0x3,%rax
>> 0x0000000000000030 <+48>: mov %rax,0x20(%rdi)
>> 0x0000000000000034 <+52>: mov $0x1,%eax
>> 0x0000000000000039 <+57>: retq
>>
>> After patch, down_read_trylock:
>>
>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>> 0x0000000000000005 <+5>: xor %eax,%eax
>> 0x0000000000000007 <+7>: lea 0x1(%rax),%rdx
>> 0x000000000000000b <+11>: lock cmpxchg %rdx,(%rdi)
>> 0x0000000000000010 <+16>: jne 0x29 <down_read_trylock+41>
>> 0x0000000000000012 <+18>: mov %gs:0x0,%rax
>> 0x000000000000001b <+27>: or $0x3,%rax
>> 0x000000000000001f <+31>: mov %rax,0x20(%rdi)
>> 0x0000000000000023 <+35>: mov $0x1,%eax
>> 0x0000000000000028 <+40>: retq
>> 0x0000000000000029 <+41>: test %rax,%rax
>> 0x000000000000002c <+44>: jns 0x7 <down_read_trylock+7>
>> 0x000000000000002e <+46>: xor %eax,%eax
>> 0x0000000000000030 <+48>: retq
>>
>> By using a rwsem microbenchmark, the down_read_trylock() rate (with a
>> load of 10 to lengthen the lock critical section) on a x86-64 system
>> before and after the patch were:
>>
>> Before Patch After Patch
>> # of Threads rlock rlock
>> ------------ ----- -----
>> 1 14,496 14,716
>> 2 8,644 8,453
>> 4 6,799 6,983
>> 8 5,664 7,190
>>
>> On a ARM64 system, the performance results were:
>>
>> Before Patch After Patch
>> # of Threads rlock rlock
>> ------------ ----- -----
>> 1 23,676 24,488
>> 2 7,697 9,502
>> 4 4,945 3,440
>> 8 2,641 1,603
> Urgh, yes LL/SC is the obvious exception that can actually do better
> here :/
>
> Will, what say you?
The ARM64 result is what I would have expected given that the change was
to optimize for the uncontended case. The x86-64 result is kind of an
anomaly to me, but I haven't bothered to dig into that.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
From: Davidlohr Bueso @ 2019-02-14 13:23 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, the arch/x86 maintainers, linux-ia64,
Tim Chen, Arnd Bergmann, Linux-sh list, Peter Zijlstra,
linux-hexagon, linuxppc-dev, Will Deacon,
Linux List Kernel Mailing, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
Linus Torvalds, Andrew Morton, linux-arm-kernel
In-Reply-To: <d7476dfb-1653-747b-b865-5597ba5fc1c1@redhat.com>
On Fri, 08 Feb 2019, Waiman Long wrote:
>I am planning to run more performance test and post the data sometimes
>next week. Davidlohr is also going to run some of his rwsem performance
>test on this patchset.
So I ran this series on a 40-core IB 2 socket with various worklods in
mmtests. Below are some of the interesting ones; full numbers and curves
at https://linux-scalability.org/rwsem-reader-spinner/
All workloads are with increasing number of threads.
-- pagefault timings: pft is an artificial pf benchmark (thus reader stress).
metric is faults/cpu and faults/sec
v5.0-rc6 v5.0-rc6
dirty
Hmean faults/cpu-1 624224.9815 ( 0.00%) 618847.5201 * -0.86%*
Hmean faults/cpu-4 539550.3509 ( 0.00%) 547407.5738 * 1.46%*
Hmean faults/cpu-7 401470.3461 ( 0.00%) 381157.9830 * -5.06%*
Hmean faults/cpu-12 267617.0353 ( 0.00%) 271098.5441 * 1.30%*
Hmean faults/cpu-21 176194.4641 ( 0.00%) 175151.3256 * -0.59%*
Hmean faults/cpu-30 119927.3862 ( 0.00%) 120610.1348 * 0.57%*
Hmean faults/cpu-40 91203.6820 ( 0.00%) 91832.7489 * 0.69%*
Hmean faults/sec-1 623292.3467 ( 0.00%) 617992.0795 * -0.85%*
Hmean faults/sec-4 2113364.6898 ( 0.00%) 2140254.8238 * 1.27%*
Hmean faults/sec-7 2557378.4385 ( 0.00%) 2450945.7060 * -4.16%*
Hmean faults/sec-12 2696509.8975 ( 0.00%) 2747968.9819 * 1.91%*
Hmean faults/sec-21 2902892.5639 ( 0.00%) 2905923.3881 * 0.10%*
Hmean faults/sec-30 2956696.5793 ( 0.00%) 2990583.5147 * 1.15%*
Hmean faults/sec-40 3422806.4806 ( 0.00%) 3352970.3082 * -2.04%*
Stddev faults/cpu-1 2949.5159 ( 0.00%) 2802.2712 ( 4.99%)
Stddev faults/cpu-4 24165.9454 ( 0.00%) 15841.1232 ( 34.45%)
Stddev faults/cpu-7 20914.8351 ( 0.00%) 22744.3294 ( -8.75%)
Stddev faults/cpu-12 11274.3490 ( 0.00%) 14733.3152 ( -30.68%)
Stddev faults/cpu-21 2500.1950 ( 0.00%) 2200.9518 ( 11.97%)
Stddev faults/cpu-30 1599.5346 ( 0.00%) 1414.0339 ( 11.60%)
Stddev faults/cpu-40 1473.0181 ( 0.00%) 3004.1209 (-103.94%)
Stddev faults/sec-1 2655.2581 ( 0.00%) 2405.1625 ( 9.42%)
Stddev faults/sec-4 84042.7234 ( 0.00%) 57996.7158 ( 30.99%)
Stddev faults/sec-7 123656.7901 ( 0.00%) 135591.1087 ( -9.65%)
Stddev faults/sec-12 97135.6091 ( 0.00%) 127054.4926 ( -30.80%)
Stddev faults/sec-21 69564.6264 ( 0.00%) 65922.6381 ( 5.24%)
Stddev faults/sec-30 51524.4027 ( 0.00%) 56109.4159 ( -8.90%)
Stddev faults/sec-40 101927.5280 ( 0.00%) 160117.0093 ( -57.09%)
With the exception of the hicup at 7 threads, things are pretty much in
the noise region for both metrics.
-- git checkout
First metric is total runtime for runs with incremental threads.
v5.0-rc6 v5.0-rc6
dirty
User 218.95 219.07
System 149.29 146.82
Elapsed 1574.10 1427.08
In this case there's a non trivial improvement (11%) in overall elapsed time.
-- reaim (which is always succeptible to rwsem changes for both mmap_sem and
i_mmap)
v5.0-rc6 v5.0-rc6
dirty
Hmean compute-1 6674.01 ( 0.00%) 6544.28 * -1.94%*
Hmean compute-21 85294.91 ( 0.00%) 85524.20 * 0.27%*
Hmean compute-41 149674.70 ( 0.00%) 149494.58 * -0.12%*
Hmean compute-61 177721.15 ( 0.00%) 170507.38 * -4.06%*
Hmean compute-81 181531.07 ( 0.00%) 180463.24 * -0.59%*
Hmean compute-101 189024.09 ( 0.00%) 187288.86 * -0.92%*
Hmean compute-121 200673.24 ( 0.00%) 195327.65 * -2.66%*
Hmean compute-141 213082.29 ( 0.00%) 211290.80 * -0.84%*
Hmean compute-161 207764.06 ( 0.00%) 204626.68 * -1.51%*
The 'compute' workload overall takes a small hit.
Hmean new_dbase-1 60.48 ( 0.00%) 60.63 * 0.25%*
Hmean new_dbase-21 6590.49 ( 0.00%) 6671.81 * 1.23%*
Hmean new_dbase-41 14202.91 ( 0.00%) 14470.59 * 1.88%*
Hmean new_dbase-61 21207.24 ( 0.00%) 21067.40 * -0.66%*
Hmean new_dbase-81 25542.40 ( 0.00%) 25542.40 * 0.00%*
Hmean new_dbase-101 30165.28 ( 0.00%) 30046.21 * -0.39%*
Hmean new_dbase-121 33638.33 ( 0.00%) 33219.90 * -1.24%*
Hmean new_dbase-141 36723.70 ( 0.00%) 37504.52 * 2.13%*
Hmean new_dbase-161 42242.51 ( 0.00%) 42117.34 * -0.30%*
Hmean shared-1 76.54 ( 0.00%) 76.09 * -0.59%*
Hmean shared-21 7535.51 ( 0.00%) 5518.75 * -26.76%*
Hmean shared-41 17207.81 ( 0.00%) 14651.94 * -14.85%*
Hmean shared-61 20716.98 ( 0.00%) 18667.52 * -9.89%*
Hmean shared-81 27603.83 ( 0.00%) 23466.45 * -14.99%*
Hmean shared-101 26008.59 ( 0.00%) 29536.96 * 13.57%*
Hmean shared-121 28354.76 ( 0.00%) 43139.39 * 52.14%*
Hmean shared-141 38509.25 ( 0.00%) 41619.35 * 8.08%*
Hmean shared-161 40496.07 ( 0.00%) 44303.46 * 9.40%*
Overall there is a small hit (in the noise level but consistent throughout
many workloads), except git-checkout which does quite well.
Thanks,
Davidlohr
^ permalink raw reply
* Re: [v3, 1/2] drivers/mtd: Use mtd->name when registering nvmem device
From: Boris Brezillon @ 2019-02-14 13:04 UTC (permalink / raw)
To: Aneesh Kumar K.V, Alban Bedel, linuxppc-dev, Boris Brezillon,
linux-mtd
Cc: Boris Brezillon
In-Reply-To: <20190211133338.30399-1-aneesh.kumar@linux.ibm.com>
From: Boris Brezillon <bbrezillon@kernel.org>
On Mon, 2019-02-11 at 13:33:37 UTC, "Aneesh Kumar K.V" wrote:
> With this patch, we use the mtd->name instead of concatenating the name with '0'
>
> Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API")
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to http://git.infradead.org/linux-mtd.git mtd/fixes, thanks.
Boris
^ permalink raw reply
* Re: [v3,2/2] drivers/mtd: Fix device registration error
From: Boris Brezillon @ 2019-02-14 13:04 UTC (permalink / raw)
To: Aneesh Kumar K.V, Alban Bedel, linuxppc-dev, Boris Brezillon,
linux-mtd
Cc: Boris Brezillon
In-Reply-To: <20190211133338.30399-2-aneesh.kumar@linux.ibm.com>
From: Boris Brezillon <bbrezillon@kernel.org>
On Mon, 2019-02-11 at 13:33:38 UTC, "Aneesh Kumar K.V" wrote:
> This change helps me to get multiple mtd device registered. Without this
> I get
>
> sysfs: cannot create duplicate filename '/bus/nvmem/devices/flash0'
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2-00557-g1ef20ef21f22 #13
> Call Trace:
> [c0000000b38e3220] [c000000000b58fe4] dump_stack+0xe8/0x164 (unreliable)
> [c0000000b38e3270] [c0000000004cf074] sysfs_warn_dup+0x84/0xb0
> [c0000000b38e32f0] [c0000000004cf6c4] sysfs_do_create_link_sd.isra.0+0x114/0x150
> [c0000000b38e3340] [c000000000726a84] bus_add_device+0x94/0x1e0
> [c0000000b38e33c0] [c0000000007218f0] device_add+0x4d0/0x830
> [c0000000b38e3480] [c0000000009d54a8] nvmem_register.part.2+0x1c8/0xb30
> [c0000000b38e3560] [c000000000834530] mtd_nvmem_add+0x90/0x120
> [c0000000b38e3650] [c000000000835bc8] add_mtd_device+0x198/0x4e0
> [c0000000b38e36f0] [c00000000083619c] mtd_device_parse_register+0x11c/0x280
> [c0000000b38e3780] [c000000000840830] powernv_flash_probe+0x180/0x250
> [c0000000b38e3820] [c00000000072c120] platform_drv_probe+0x60/0xf0
> [c0000000b38e38a0] [c0000000007283c8] really_probe+0x138/0x4d0
> [c0000000b38e3930] [c000000000728acc] driver_probe_device+0x13c/0x1b0
> [c0000000b38e39b0] [c000000000728c7c] __driver_attach+0x13c/0x1c0
> [c0000000b38e3a30] [c000000000725130] bus_for_each_dev+0xa0/0x120
> [c0000000b38e3a90] [c000000000727b2c] driver_attach+0x2c/0x40
> [c0000000b38e3ab0] [c0000000007270f8] bus_add_driver+0x228/0x360
> [c0000000b38e3b40] [c00000000072a2e0] driver_register+0x90/0x1a0
> [c0000000b38e3bb0] [c00000000072c020] __platform_driver_register+0x50/0x70
> [c0000000b38e3bd0] [c00000000105c984] powernv_flash_driver_init+0x24/0x38
> [c0000000b38e3bf0] [c000000000010904] do_one_initcall+0x84/0x464
> [c0000000b38e3cd0] [c000000001004548] kernel_init_freeable+0x530/0x634
> [c0000000b38e3db0] [c000000000011154] kernel_init+0x1c/0x168
> [c0000000b38e3e20] [c00000000000bed4] ret_from_kernel_thread+0x5c/0x68
> mtd mtd1: Failed to register NVMEM device
>
> With the change we now have
>
> root@(none):/sys/bus/nvmem/devices# ls -al
> total 0
> drwxr-xr-x 2 root root 0 Feb 6 20:49 .
> drwxr-xr-x 4 root root 0 Feb 6 20:49 ..
> lrwxrwxrwx 1 root root 0 Feb 6 20:49 flash@0 -> ../../../devices/platform/ibm,opal:flash@0/mtd/mtd0/flash@0
> lrwxrwxrwx 1 root root 0 Feb 6 20:49 flash@1 -> ../../../devices/platform/ibm,opal:flash@1/mtd/mtd1/flash@1
>
> Fixes: acfe63ec1c59 ("mtd: Convert to using %pOFn instead of device_node.name")
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to http://git.infradead.org/linux-mtd.git mtd/fixes, thanks.
Boris
^ permalink raw reply
* Re: [PATCH v4 2/3] locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs
From: Peter Zijlstra @ 2019-02-14 11:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-ia64@vger.kernel.org, Linux-sh list, Will Deacon,
Linux Kernel Mailing List, H. Peter Anvin, sparclinux,
linux-riscv, Christoph Hellwig, Linux-Arch, linux-s390,
Davidlohr Bueso, linux-c6x-dev, open list:QUALCOMM HEXAGON...,
the arch/x86 maintainers, Ingo Molnar, Waiman Long,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
linux-um, linuxppc-dev, linux-m68k, Openrisc, Borislav Petkov,
Thomas Gleixner, Linux ARM, Parisc List, Linus Torvalds,
linux-mips, alpha, nios2-dev, Andrew Morton, Tim Chen
In-Reply-To: <CAMuHMdVe9J4LmbLz8nHsW2JSVt8EQHTKswtc+-53pD-DBxgwSw@mail.gmail.com>
On Thu, Feb 14, 2019 at 11:54:47AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 13, 2019 at 11:01 PM Waiman Long <longman@redhat.com> wrote:
> > Currently, we have two different implementation of rwsem:
> > 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> > 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
> >
> > As we are going to use a single generic implementation for rwsem-xadd.c
> > and no architecture-specific code will be needed, there is no point
> > in keeping two different implementations of rwsem. In most cases, the
> > performance of rwsem-spinlock.c will be worse. It also doesn't get all
> > the performance tuning and optimizations that had been implemented in
> > rwsem-xadd.c over the years.
> >
> > For simplication, we are going to remove rwsem-spinlock.c and make all
> > architectures use a single implementation of rwsem - rwsem-xadd.c.
> >
> > All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHM
> > in the code are removed.
> >
> > Suggested-by: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> Note that this conflicts with "[PATCH 03/11] kernel/locks: consolidate
> RWSEM_GENERIC_* options"
> https://lore.kernel.org/lkml/20190213174005.28785-4-hch@lst.de/
*sigh*.. of that never was Cc'ed to locking people :/
^ permalink raw reply
* Re: [PATCH v2] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti @ 2019-02-14 10:59 UTC (permalink / raw)
To: Vlastimil Babka, Dave Hansen, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Alexander Viro, Mike Kravetz,
linux-arm-kernel, linux-kernel, linuxppc-dev, linux-s390,
linux-fsdevel, linux-mm
In-Reply-To: <bcffa37e-22cd-f0d7-ee85-769c0d54520a@suse.cz>
On 02/14/2019 10:52 AM, Vlastimil Babka wrote:
> On 2/13/19 8:30 PM, Dave Hansen wrote:
>>> -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA)
>>> +#ifdef CONFIG_COMPACTION_CORE
>>> static __init int gigantic_pages_init(void)
>>> {
>>> /* With compaction or CMA we can allocate gigantic pages at runtime */
>>> diff --git a/fs/Kconfig b/fs/Kconfig
>>> index ac474a61be37..8fecd3ea5563 100644
>>> --- a/fs/Kconfig
>>> +++ b/fs/Kconfig
>>> @@ -207,8 +207,9 @@ config HUGETLB_PAGE
>>> config MEMFD_CREATE
>>> def_bool TMPFS || HUGETLBFS
>>>
>>> -config ARCH_HAS_GIGANTIC_PAGE
>>> +config COMPACTION_CORE
>>> bool
>>> + default y if (MEMORY_ISOLATION && MIGRATION) || CMA
>> This takes a hard dependency (#if) and turns it into a Kconfig *default*
>> that can be overridden. That seems like trouble.
>>
>> Shouldn't it be:
>>
>> config COMPACTION_CORE
>> def_bool y
>> depends on (MEMORY_ISOLATION && MIGRATION) || CMA
> Agreed. Also I noticed that it now depends on MIGRATION instead of
> COMPACTION. That intention is correct IMHO, but will fail to
> compile/link when both COMPACTION and CMA are disabled, and would need
> more changes in mm/internal.h and mm/compaction.c (possibly just
> replacing CMA in all "if defined CONFIG_COMPACTION || defined
> CONFIG_CMA" instances with COMPACTION_CORE, but there might be more
> problems, wanna try? :)
Let's be honest, that's a "typo" :) Migration is logical to me but
that's because I don't know much about compaction. Thanks for
noticing it.
I'll take a look at what you propose to do too.
>
> Also, I realized that COMPACTION_CORE is a wrong name, sorry about that.
> What the config really provides is alloc_contig_range(), so it should be
> named either CONFIG_CMA_CORE (as it provides contiguous memory
> allocation, but not the related reservation and accounting), or
> something like CONFIG_CONTIG_ALLOC. I would also move it from fs/Kconfig
> to mm/Kconfig.
No problem, I was not inspired either. I'll send a v3 with the renaming
you propose.
> Thanks!
Thank you.
Alex
^ permalink raw reply
* Re: [PATCH v4 2/3] locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs
From: Geert Uytterhoeven @ 2019-02-14 10:54 UTC (permalink / raw)
To: Waiman Long, Christoph Hellwig
Cc: linux-ia64@vger.kernel.org, Linux-sh list, Peter Zijlstra,
Will Deacon, Linux Kernel Mailing List, H. Peter Anvin,
sparclinux, linux-riscv, Linux-Arch, linux-s390, Davidlohr Bueso,
linux-c6x-dev, open list:QUALCOMM HEXAGON...,
the arch/x86 maintainers, Ingo Molnar,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
linux-um, linuxppc-dev, linux-m68k, Openrisc, Borislav Petkov,
Thomas Gleixner, Linux ARM, Parisc List, Linus Torvalds,
linux-mips, alpha, nios2-dev, Andrew Morton, Tim Chen
In-Reply-To: <1550095217-12047-3-git-send-email-longman@redhat.com>
On Wed, Feb 13, 2019 at 11:01 PM Waiman Long <longman@redhat.com> wrote:
> Currently, we have two different implementation of rwsem:
> 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
>
> As we are going to use a single generic implementation for rwsem-xadd.c
> and no architecture-specific code will be needed, there is no point
> in keeping two different implementations of rwsem. In most cases, the
> performance of rwsem-spinlock.c will be worse. It also doesn't get all
> the performance tuning and optimizations that had been implemented in
> rwsem-xadd.c over the years.
>
> For simplication, we are going to remove rwsem-spinlock.c and make all
> architectures use a single implementation of rwsem - rwsem-xadd.c.
>
> All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHM
> in the code are removed.
>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Waiman Long <longman@redhat.com>
Note that this conflicts with "[PATCH 03/11] kernel/locks: consolidate
RWSEM_GENERIC_* options"
https://lore.kernel.org/lkml/20190213174005.28785-4-hch@lst.de/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 03/11] kernel/locks: consolidate RWSEM_GENERIC_* options
From: Geert Uytterhoeven @ 2019-02-14 10:52 UTC (permalink / raw)
To: Christoph Hellwig, Waiman Long
Cc: Linux-Arch, linux-xtensa, linux-s390, linux-kbuild,
Linux Kernel Mailing List, Masahiro Yamada, linux-riscv,
linuxppc-dev
In-Reply-To: <20190213174005.28785-4-hch@lst.de>
On Thu, Feb 14, 2019 at 12:08 AM Christoph Hellwig <hch@lst.de> wrote:
> Introduce one central definition of RWSEM_XCHGADD_ALGORITHM and
> RWSEM_GENERIC_SPINLOCK in kernel/Kconfig.locks and let architectures
> select RWSEM_XCHGADD_ALGORITHM if they want it, otherwise default to
> the spinlock version.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Note that this conflicts with "[PATCH v4 2/3] locking/rwsem: Remove
rwsem-spinlock.c & use rwsem-xadd.c for all archs"
https://lore.kernel.org/lkml/1550095217-12047-3-git-send-email-longman@redhat.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox