All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Hou Tao <houtao1@huawei.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	peterz@infradead.org, Oleg Nesterov <oleg@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Jan Kara <jack@suse.cz>
Subject: Re: [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for read_count
Date: Tue, 29 Sep 2020 18:49:59 +0100	[thread overview]
Message-ID: <20200929174958.GG14317@willie-the-truck> (raw)
In-Reply-To: <522e22a5-98e8-3a99-8f82-dc3789508638@huawei.com>

On Thu, Sep 24, 2020 at 07:55:19PM +0800, Hou Tao wrote:
> The following is the newest performance data:
> 
> aarch64 host (4 sockets, 24 cores per sockets)
> 
> * v4.19.111
> 
> no writer, reader cn                                | 24        | 48        | 72        | 96
> rate of percpu_down_read/percpu_up_read per second  |
> default: use __this_cpu_inc|dec()                   | 166129572 | 166064100 | 165963448 | 165203565
> patched: use this_cpu_inc|dec()                     |  87727515 |  87698669 |  87675397 |  87337435
> modified: local_irq_save + __this_cpu_inc|dec()     |  15470357	|  15460642 |  15439423	|  15377199
> 
> * v4.19.111+ [1]
> 
> modified: use this_cpu_inc|dec() + LSE atomic       |   8224023 |   8079416 |	7883046 |   7820350
> 
> * 5.9-rc6
> 
> no writer, reader cn                                | 24        | 48        | 72        | 96
> rate of percpu_down_read/percpu_up_read per second  |
> reverted: use __this_cpu_inc|dec() + revert 91fc957c| 169664061 | 169481176 | 168493488 | 168844423
> reverted: use __this_cpu_inc|dec()                  |  78355071 |  78294285 |  78026030 |  77860492
> modified: use this_cpu_inc|dec() + no LSE atomic    |  64291101 |  64259867 |  64223206 |  63992316
> default: use this_cpu_inc|dec() + LSE atomic        |  16231421 |  16215618 |  16188581 |  15959290
> 
> It seems that enabling LSE atomic has a negative impact on performance under this test scenario.
> 
> And it is astonished to me that for my test scenario the performance of v5.9-rc6 is just one half of v4.19.
> The bisect finds the culprit is 91fc957c9b1d6 ("arm64/bpf: don't allocate BPF JIT programs in module memory").
> If reverting the patch brute-forcibly under 5.9-rc6 [2], the performance will be the same with
> v4.19.111 (169664061 vs 166129572). I have had the simplified test module [3] and .config attached [4],
> so could you please help to check what the problem is ?

I have no idea how that patch can be responsible for this :/ Have you
confirmed that the bisection is not bogus?

Ard, do you have any ideas?

Will

  reply	other threads:[~2020-09-29 17:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 14:07 [RFC PATCH] locking/percpu-rwsem: use this_cpu_{inc|dec}() for read_count Hou Tao
2020-09-15 15:06 ` peterz
2020-09-15 15:31   ` Oleg Nesterov
2020-09-15 15:51     ` peterz
2020-09-15 16:03       ` peterz
2020-09-15 16:11         ` Will Deacon
2020-09-15 18:11           ` peterz
2020-09-16  8:20             ` Will Deacon
2020-09-15 16:47         ` Oleg Nesterov
2020-09-16 12:32         ` Hou Tao
2020-09-16 12:51           ` peterz
2020-09-17  8:48           ` Will Deacon
2020-09-24 11:55             ` Hou Tao
2020-09-29 17:49               ` Will Deacon [this message]
2020-09-29 18:07                 ` Ard Biesheuvel
2020-09-17 10:51           ` Boaz Harrosh
2020-09-17 12:01             ` Oleg Nesterov
2020-09-17 12:48               ` Matthew Wilcox
2020-09-17 13:22                 ` peterz
2020-09-17 13:34                 ` Oleg Nesterov
2020-09-17 13:46                 ` Boaz Harrosh
2020-09-17 14:46                   ` Christoph Hellwig
2020-09-18  9:07               ` Jan Kara
2020-09-18 10:01                 ` peterz
2020-09-18 10:04                   ` peterz
2020-09-18 10:07                     ` peterz
2020-09-18 10:12                   ` peterz
2020-09-18 10:48                     ` Oleg Nesterov
2020-09-18 11:03                       ` peterz
2020-09-18 13:09                         ` Oleg Nesterov
2020-09-18 13:26                           ` Jan Kara
2020-09-20 23:49                             ` Dave Chinner
2020-09-18  8:36 ` [tip: locking/urgent] locking/percpu-rwsem: Use this_cpu_{inc,dec}() " tip-bot2 for Hou Tao

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20200929174958.GG14317@willie-the-truck \
    --to=will@kernel.org \
    --cc=ardb@kernel.org \
    --cc=cl@linux.com \
    --cc=dennis@kernel.org \
    --cc=houtao1@huawei.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

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

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