From: Tejun Heo <tj@kernel.org>
To: Tao Cui <cuitao@kylinos.cn>
Cc: hannes@cmpxchg.org, mkoutny@suse.com, cgroups@vger.kernel.org
Subject: Re: [PATCH v2 0/4] cgroup/rdma: add rdma.peak and rdma.events[.local]
Date: Wed, 13 May 2026 10:27:49 -1000 [thread overview]
Message-ID: <f30b301f9a7dee1fc458f1c7964f731a@kernel.org> (raw)
In-Reply-To: <20260513104956.373216-1-cuitao@kylinos.cn>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
Hello,
v1 points are fully addressed. A few more on v2:
* In rdmacg_resource_set_max(), the new "rpool has peak/events" check
uses `goto dev_err` to skip free_cg_rpool_locked(). It works
because ret is still 0 at that point, but dev_err is the error
label and this isn't an error path. Restructure so the free is
guarded by an if, or rename the label.
* By the end of patch 3, the rpool-keep predicate is five lines
duplicated in uncharge_cg_locked() and rdmacg_resource_set_max().
Worth extracting into a rpool_has_persistent_state() helper — a
sixth counter later then changes one site, not two.
* Switching rdmacg_event_locked() from get_ to find_ avoids the
spurious-rpool problem I raised in v1, but it also means
ancestors of over_cg without a prior rpool for this device
silently drop the hierarchical event. Now that the rpool-keep
check covers event counters, get_ + keep-alive would give full
hierarchical coverage without the issue from v1 (rpools getting
freed on the next uncharge). The struct is small and rpool
presence isn't user-observable. Worth reconsidering — or, if you
keep find_, note the caveat in the rdma.events documentation.
* Patch 3 also extends rdma.events with hierarchical alloc_fail
but the commit message only describes rdma.events.local. Mention
the rdma.events change.
* In rdmacg_events_show() / rdmacg_events_local_show(), the
`(s64)READ_ONCE(u64) ... %lld` pattern can drop the cast and use
%llu.
Thanks.
--
tejun
prev parent reply other threads:[~2026-05-13 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 10:49 [PATCH v2 0/4] cgroup/rdma: add rdma.peak and rdma.events[.local] Tao Cui
2026-05-13 10:49 ` [PATCH v2 1/4] cgroup/rdma: add rdma.peak for per-device peak usage tracking Tao Cui
2026-05-13 10:49 ` [PATCH v2 2/4] cgroup/rdma: add rdma.events to track resource limit exhaustion Tao Cui
2026-05-13 10:49 ` [PATCH v2 3/4] cgroup/rdma: add rdma.events.local for per-cgroup allocation failure attribution Tao Cui
2026-05-13 10:49 ` [PATCH v2 4/4] cgroup/rdma: document rdma.peak, rdma.events and rdma.events.local Tao Cui
2026-05-13 20:27 ` Tejun Heo [this message]
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=f30b301f9a7dee1fc458f1c7964f731a@kernel.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=cuitao@kylinos.cn \
--cc=hannes@cmpxchg.org \
--cc=mkoutny@suse.com \
/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.