[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZCY8p/i6DR2tXPLP@slm.duckdns.org>
Date: Thu, 30 Mar 2023 15:51:35 -1000
From: Tejun Heo <tj@...nel.org>
To: Hugh Dickins <hughd@...gle.com>
Cc: Yosry Ahmed <yosryahmed@...gle.com>,
Shakeel Butt <shakeelb@...gle.com>,
Josef Bacik <josef@...icpanda.com>,
Jens Axboe <axboe@...nel.dk>,
Zefan Li <lizefan.x@...edance.com>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
Vasily Averin <vasily.averin@...ux.dev>,
cgroups@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
bpf@...r.kernel.org
Subject: Re: [RFC PATCH 1/7] cgroup: rstat: only disable interrupts for the
percpu lock
Hello, Hugh.
On Wed, Mar 29, 2023 at 01:38:48PM -0700, Hugh Dickins wrote:
> > So, in general, there's a trade off between local irq service latency and
> > inducing global lock contention when using unprotected locks. With more and
> > more CPUs, the balance keeps shifting. The balance still very much depends
> > on the specifics of a given lock but yeah I think it's something we need to
> > be a lot more careful about now.
>
> And this looks a very plausible argument to me: I'll let it sink in.
Another somewhat relevant change is that flipping irq on/off used to be
relatively expensive on older x86 cpus. I forget all details about when and
how much but they should be a lot cheaper now. No idea about !x86 cpus tho.
> But I hadn't heard that the RT folks were clamouring for more irq disabling:
> perhaps they partition their machines with more care, and are not devotees
> of high CPU counts.
I think RT folks care a lot more about raw IRQ disables. These shouldn't
actually disable IRQs on RT kernels.
Thanks.
--
tejun
Powered by blists - more mailing lists