mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: 刘嵩 <liusong@linux.alibaba.com>
To: Tejun Heo <tj@kernel.org>
Cc: lizefan.x@bytedance.com, hannes@cmpxchg.org,
	"Michal Koutný" <mkoutny@suse.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] sched, cgroup: cgroup1 can also take the non-RUNTIME_INF min
Date: Wed, 11 Sep 2024 09:53:27 +0800	[thread overview]
Message-ID: <784F48E6-C07E-4A38-B45B-BD2D66677894@linux.alibaba.com> (raw)
In-Reply-To: <ZuCe0U1Kwr0hYoOz@slm.duckdns.org>



> 2024年9月11日 03:32,Tejun Heo <tj@kernel.org> 写道:
> 
> On Tue, Sep 10, 2024 at 03:48:32PM +0800, Liu Song wrote:
>> For the handling logic of child_quota, there is no need to distinguish
>> between cgroup1 and cgroup2, so unify the handling logic here.
>> 
>> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> 
> It doens't make much sense to change the interface for cgroup1 at this
> point. Let's please leave it as-is.
> 
> Thanks.
> 
> -- 
> tejun

Hi

In scenarios involving secure shared containers (like Kata), where containers are deployed
on VMs and constrained by CPU runtime using quotas, the concept of vCPUs comes into
play.

If the CPU limit set by Kubernetes is less than the actual number of vCPUs, meaning the
CPU count derived from the quota is less than the vCPU count, then when a user runs lscpu
inside the container, the reported CPU count will be greater than the container's quota.

If the user uses this reported count to calculate quota and attempts to set it for their own
sub-container, it will result in an error under cgroup1, whereas the same operation will
succeed under cgroup2. To avoid imposing extra learning costs on users, unifying the
handling logic in this regard is still beneficial.

Thanks

      reply	other threads:[~2024-09-11  1:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10  7:48 Liu Song
2024-09-10  9:35 ` Michal Koutný
2024-09-10 10:05   ` 刘嵩
2024-09-10 10:49 ` Phil Auld
2024-09-10 11:13   ` 刘嵩
2024-09-10 12:12     ` Phil Auld
2024-09-10 19:32 ` Tejun Heo
2024-09-11  1:53   ` 刘嵩 [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=784F48E6-C07E-4A38-B45B-BD2D66677894@linux.alibaba.com \
    --to=liusong@linux.alibaba.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --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

all inboxes | Powered by JetHome®