[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <454qatlzbtbfsh3vub7qrnropuyux4lxsokxt72fbiy2fpy2pu@dmfi22u5d64k>
Date: Tue, 1 Apr 2025 18:59:31 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Yosry Ahmed <yosry.ahmed@...ux.dev>, Greg Thelen <gthelen@...gle.com>,
Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>, Eric Dumazet <edumzaet@...gle.com>, cgroups@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH] cgroup/rstat: avoid disabling irqs for O(num_cpu)
On Tue, Apr 01, 2025 at 05:46:41PM +0200, Mateusz Guzik <mjguzik@...il.com> wrote:
> Is this really going to suffer for toggling every 8 CPUs? that's a 50x
> factor reduction
As per the original patch, there's ~10x saving in max holding irqs-off,
naïevely thinking aggregating it flushing by 8 CPUs could reduce it to
(10/8) ~1.25x saving only.
(OTOH, it's not 400x effect, so it's not explained completely, not all
CPUs are same.) I can imagine the balanced value with this information
would be around 20 CPUs (sqrt(400)).
But the issue is it could as well be 4 or 32 or 8. Starting with 1 is
the simplest approach without introducing magic constants or heuristics.
> the temp changes like the to stay for a long time.
That'd mean that no one notices the performance impact there :-)
It can be easily changed later too.
> that said, there is bigger fish to fry elsewhere and I have no stake
> in this code, so I'm not going to mail any further about this.
Thank you for spending your effort on this, it's useful reference for
the future!
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists