mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] percpu_counter: increase batch count
Date: Mon, 22 Feb 2021 14:53:55 -0700	[thread overview]
Message-ID: <5eea419a-e0b5-2652-3f35-5042d7925e23@kernel.dk> (raw)
In-Reply-To: <alpine.LSU.2.11.2102221309570.4728@eggly.anvils>

On 2/22/21 2:31 PM, Hugh Dickins wrote:
> On Thu, 18 Feb 2021, Jens Axboe wrote:
>> On 2/18/21 4:16 PM, Andrew Morton wrote:
>>> On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>>>
>>>> Currently we cap the batch count at max(32, 2*nr_online_cpus), which these
>>>> days is kind of silly as systems have gotten much bigger than in 2009 when
>>>> this heuristic was introduced.
>>>>
>>>> Bump it to capping it at 256 instead. This has a noticeable improvement
>>>> for certain io_uring workloads, as io_uring tracks per-task inflight count
>>>> using percpu counters.
> 
> I want to quibble with the word "capping" here, it's misleading -
> but I'm sorry I cannot think of the right word.

Agree, it's not the best wording. And if you can't think of a better
one, then I'm at a loss too :-)

> The macro is max() not min(): you're making an improvement for
> certain io_uring workloads on machines with 1 to 15 cpus, right?
> Does "bigger than in 2009" apply to those?

Right, that actually had me confused. The box in question has 64 threads,
so my effective count was 128, or 256 with the patch.

> Though, io_uring could as well use percpu_counter_add_batch() instead?

That might be a simpler/better choice!

> (Yeah, this has nothing to do with me really, but I was looking at
> percpu_counter_compare() just now, for tmpfs reasons, so took more
> interest.  Not objecting to a change, but the wording leaves me
> wondering if the patch does what you think - or, not for the
> first time, I'm confused.)

I don't think you're confused, and honestly I think using the batch
version instead would likely improve our situation without potentially
changing behavior for everyone else. So it's likely the right way to go.

Thanks Hugh!

-- 
Jens Axboe


  reply	other threads:[~2021-02-22 21:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18 21:36 Jens Axboe
2021-02-18 23:16 ` Andrew Morton
2021-02-18 23:23   ` Jens Axboe
2021-02-22 21:31     ` Hugh Dickins
2021-02-22 21:53       ` Jens Axboe [this message]
2021-02-22 22:14         ` Hugh Dickins

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=5eea419a-e0b5-2652-3f35-5042d7925e23@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome