From: "Michal Koutný" <mkoutny@suse.com>
To: Peng Yu <yupeng0921@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>, Tejun Heo <tj@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Josef Bacik <josef@toxicpanda.com>, Jens Axboe <axboe@kernel.dk>,
Maurizio Lombardi <mlombard@arkamax.eu>,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] nvmet: add cgroup_path to charge namespace I/O to a cgroup
Date: Wed, 23 Sep 2026 17:53:53 +0200 [thread overview]
Message-ID: <arP0TmdK3FnNfbwH@localhost.localdomain> (raw)
In-Reply-To: <20260923152653.40953-1-yupeng0921@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
On Wed, Sep 23, 2026 at 08:26:53AM -0700, Peng Yu <yupeng0921@gmail.com> wrote:
> Scenario:
> * Create multiple nvmet subsystems/namespaces.
> * The namespaces are backed by different LVM logical volumes.
> * Some of the logical volumes share the same physical volumes.
Why are LVMs mentioned? (The test scenario doesn't seem to use those.
And the example is backed by RAM, so where would be any IO to control at
all? Note: I'm only giving this part of my attention span.)
> * The subsystems are exported to different users.
> * We should provide each user a specific iops/bps quota, thus a noisy
> neighbor won't impact the performance of other logical volumes.
Why cannot you place users into respective cgroups and configure
appropriate per-device limits?
Thanks for providing more context about the scenario so that I can
understand what's the goal and obstacle.
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
next prev parent reply other threads:[~2026-09-23 15:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 15:26 Peng Yu
2026-09-23 15:53 ` Michal Koutný [this message]
2026-09-24 4:34 ` peng yu
2026-09-23 16:38 ` Tejun Heo
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=arP0TmdK3FnNfbwH@localhost.localdomain \
--to=mkoutny@suse.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mlombard@arkamax.eu \
--cc=sagi@grimberg.me \
--cc=tj@kernel.org \
--cc=yupeng0921@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®