From: Jason Gunthorpe <jgg@ziepe.ca>
To: Tao Cui <cuitao@kylinos.cn>
Cc: cgroups@vger.kernel.org, hannes@cmpxchg.org, leon@kernel.org,
linux-rdma@vger.kernel.org, mkoutny@suse.com, tj@kernel.org
Subject: Re: [RFC PATCH rdma-next 0/5] cgroup/rdma: add per-type resource accounting for QP, MR and MR memory
Date: Thu, 28 May 2026 10:06:22 -0300 [thread overview]
Message-ID: <20260528130622.GO2487554@ziepe.ca> (raw)
In-Reply-To: <20260528075537.2170697-1-cuitao@kylinos.cn>
On Thu, May 28, 2026 at 03:55:37PM +0800, Tao Cui wrote:
> Hi,Jason
>
> > memory pin accounting should ideally be limited by the cgroup directly
> > but we argued about that for a while and could never get an agreement
> > of an acceptable implementation. There are many nasty corner cases
> > around cgroups and fork and other cases IIRC
> >
> > So I'm not sure if making it rdma specific can easially solve these
> > problems
>
> Thanks for the detailed context. I understand the concern — generic
> pinned-page accounting at the memcg level has difficult ownership
> semantics around fork(), cgroup migration, shared mappings, and page
> lifetime tracking.
>
> The intent of mr_mem is narrower and RDMA-scoped. It is not page-level
> ownership tracking — it is object-based accounting tied to the MR
> lifetime:
>
> - charged at MR registration time
> - uncharged at MR destruction time
> - the charge lives with the MR's creating cgroup for the entire
> lifetime of the MR object
Okay, that's an interesting framing. Perhaps it can work, you should
include this in the commit message and be sure to CC the cgroup
people.
Jason
prev parent reply other threads:[~2026-05-28 13:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 5:55 [RFC PATCH rdma-next 0/5] cgroup/rdma: add per-type resource accounting for QP, MR and MR memory Tao Cui
2026-05-25 5:55 ` [RFC PATCH rdma-next 1/5] cgroup/rdma: extend charge/uncharge API with s64 amount parameter Tao Cui
2026-05-25 5:55 ` [RFC PATCH rdma-next 2/5] cgroup/rdma: add QP per-type resource counting Tao Cui
2026-05-25 5:55 ` [RFC PATCH rdma-next 3/5] cgroup/rdma: add MR " Tao Cui
2026-05-25 5:55 ` [RFC PATCH rdma-next 4/5] cgroup/rdma: add MR memory size " Tao Cui
2026-05-25 5:55 ` [RFC PATCH rdma-next 5/5] cgroup/rdma: update cgroup resource list for QP, MR and MR_MEM Tao Cui
2026-05-25 13:43 ` [RFC PATCH rdma-next 0/5] cgroup/rdma: add per-type resource accounting for QP, MR and MR memory Jason Gunthorpe
2026-05-27 11:28 ` Tao Cui
2026-05-27 13:34 ` Jason Gunthorpe
2026-05-28 7:55 ` Tao Cui
2026-05-28 13:06 ` Jason Gunthorpe [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=20260528130622.GO2487554@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=cgroups@vger.kernel.org \
--cc=cuitao@kylinos.cn \
--cc=hannes@cmpxchg.org \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mkoutny@suse.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