From: Yosry Ahmed <yosryahmed@google.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
Waiman Long <longman@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
Jesper Dangaard Brouer <jesper@cloudflare.com>,
"David S. Miller" <davem@davemloft.net>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Shakeel Butt <shakeelb@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
kernel-team <kernel-team@cloudflare.com>,
cgroups@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
Netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Ivan Babrou <ivan@cloudflare.com>
Subject: Re: Advice on cgroup rstat lock
Date: Wed, 17 Apr 2024 19:04:50 -0700 [thread overview]
Message-ID: <CAJD7tkYnSRwJTpXxSnGgo-i3-OdD7cdT-e3_S_yf7dSknPoRKw@mail.gmail.com> (raw)
In-Reply-To: <f6daabzdesdwo7zdouexow5mdub3qnzr7e67lonmhh3itjgk5j@qw3xpvqoyb7j>
[..]
> > > I personally don't like mem_cgroup_flush_stats_ratelimited() very
> > > much, because it is time-based (unlike memcg_vmstats_needs_flush()),
> > > and a lot of changes can happen in a very short amount of time.
> > > However, it seems like for some workloads it's a necessary evil :/
> > >
>
> Other than obj_cgroup_may_zswap(), there is no other place which really
> need very very accurate stats. IMO we should actually make ratelimited
> version the default one for all the places. Stats will always be out of
> sync for some time window even with non-ratelimited flush and I don't
> see any place where 2 second old stat would be any issue.
We disagreed about this before, and I am not trying to get you to
debate this with me again :)
I just prefer that we avoid this if possible. We have seen cases where
the 2 sec window caused issues. Not because 2 sec is a long time, but
because userspace reads the stats after an event occurs (e.g.
proactive reclaim), but gets stats from before the event.
[..]
>
> >
> >
> > With a mutex lock contention will be less obvious, as converting this to
> > a mutex avoids multiple CPUs spinning while waiting for the lock, but
> > it doesn't remove the lock contention.
> >
>
> I don't like global sleepable locks as those are source of priority
> inversion issues on highly utilized multi-tenant systems but I still
> need to see how you are handling that.
For context, this was discussed before as well in [1].
[1]https://lore.kernel.org/lkml/CALvZod441xBoXzhqLWTZ+xnqDOFkHmvrzspr9NAr+nybqXgS-A@mail.gmail.com/
next prev parent reply other threads:[~2024-04-18 2:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7cd05fac-9d93-45ca-aa15-afd1a34329c6@kernel.org>
[not found] ` <20240319154437.GA144716@cmpxchg.org>
[not found] ` <56556042-5269-4c7e-99ed-1a1ab21ac27f@kernel.org>
[not found] ` <CAJD7tkYbO7MdKUBsaOiSp6-qnDesdmVsTCiZApN_ncS3YkDqGQ@mail.gmail.com>
[not found] ` <bf94f850-fab4-4171-8dfe-b19ada22f3be@kernel.org>
[not found] ` <CAJD7tkbn-wFEbhnhGWTy0-UsFoosr=m7wiJ+P96XnDoFnSH7Zg@mail.gmail.com>
2024-04-09 11:08 ` Advice on cgroup rstat lock Jesper Dangaard Brouer
2024-04-09 15:37 ` Waiman Long
2024-04-09 16:45 ` Yosry Ahmed
2024-04-09 16:59 ` Waiman Long
2024-04-11 10:17 ` Jesper Dangaard Brouer
2024-04-11 17:22 ` Yosry Ahmed
2024-04-12 19:26 ` Jesper Dangaard Brouer
2024-04-12 19:51 ` Yosry Ahmed
2024-04-16 14:22 ` Jesper Dangaard Brouer
2024-04-16 18:41 ` Shakeel Butt
2024-04-18 2:04 ` Yosry Ahmed [this message]
2024-04-11 10:52 ` Arnaldo Carvalho de Melo
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=CAJD7tkYnSRwJTpXxSnGgo-i3-OdD7cdT-e3_S_yf7dSknPoRKw@mail.gmail.com \
--to=yosryahmed@google.com \
--cc=acme@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=bristot@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=hannes@cmpxchg.org \
--cc=hawk@kernel.org \
--cc=ivan@cloudflare.com \
--cc=jesper@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shakeelb@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).