Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Waiman Long <longman@xxxxxxxxxx>
- Subject: Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 8 Feb 2019 16:03:43 -0800
- Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Will Deacon <will.deacon@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linux List Kernel Mailing <linux-kernel@xxxxxxxxxxxxxxx>, linux-alpha@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-hexagon@xxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, Linux-sh list <linux-sh@xxxxxxxxxxxxxxx>, sparclinux@xxxxxxxxxxxxxxx, linux-xtensa@xxxxxxxxxxxxxxxx, linux-arch <linux-arch@xxxxxxxxxxxxxxx>, "the arch/x86 maintainers" <x86@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Davidlohr Bueso <dave@xxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
- In-reply-to: <d7476dfb-1653-747b-b865-5597ba5fc1c1@redhat.com>
- References: <1549566446-27967-1-git-send-email-longman@redhat.com> <CAHk-=wjfyrFBjifzmgMVrkrvEePEPaBTDq7D=f2i5kD2E=SqRQ@mail.gmail.com> <d7476dfb-1653-747b-b865-5597ba5fc1c1@redhat.com>
On Fri, Feb 8, 2019 at 12:31 PM Waiman Long <longman@xxxxxxxxxx> wrote:
>
> > (b) what's the new fastpath case
>
> The only change in the fastpath is the use of cmpxchg for writer lock.
.. since a big deal here was about using the generic atomic accessor
functions, I really was looking forward to seeing the *actual* fast
path code generation.
In other words, right now I have very little visibility in how it
actually affects the code. Looking at the patches themselves doesn't
make it obvious. I was hoping for the overview to really explain the
whole "before and after" situation, and it didn't. Not at the high
level, and not at a low level. And no performance numbers in the
overview either.
And yes, I see the numbers in the patches, but what I really hoped for
was some real load numbers. In particular, I would have loved to see
numbers from th ekernel test robot "will-it-scale.per_thread_ops"
case, which is the one that had a 65% regression due to the lack of
reader spinning.
So I was kind of hoping to hear whether that regression is basically
entirely gone with this patch series, or if we still have a regression
due to the extra downgrade, or what?
Linus
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]