cgroups.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Malat <oss@malat.biz>
To: cgroups@vger.kernel.org
Cc: longman@redhat.com, tj@kernel.org
Subject: [RFC/POC]: Make cpuset.cpus.effective independent of cpuset.cpus
Date: Thu, 21 Mar 2024 22:33:03 +0100	[thread overview]
Message-ID: <Zfynj56eDdCSdIxv@ntb.petris.klfree.czf> (raw)

Hi!
I have tried to use the new remote cgroup feature and I find the
interface unfriendly - requiring cpuset.cpus.exclusive to be a subset
of cpuset.cpus requires the program, which wants to isolate a CPU for
some RT activity, to know what CPUs all ancestor cgroups want to use.

For example consider cgroup hierarchy c1/c2/c3 where my program is
running and wants to isolate CPU N, so
 - It creates new c1/c2/c3/rt cgroup
 - It adds N to cpuset.cpus.exclusive of rt, c3 and c2 cgroup
   (cpuset.cpus.exclusive |= N)
 - Now it should do the same with cpuset.cpus, but that's not possible
   if ancestors cpuset.cpus is empty, which is common configuration and
   there is no good way how to set it in that case.

My proposal is to
 - Not require cpuset.cpus.exclusive to be a subset of cpuset.cpus
 - Create remote cgroup if cpuset.cpus is empty and local cgroup if it's
   set, to give the user explicit control on what cgroup is created.

I have prepared change to test my idea (the next mail). I haven't tested it
thoroughly yet, but I wanted to open the discussion on this topic to know
if such a change could be accepted and I should burn more time on it.

BR,
  Petr

             reply	other threads:[~2024-03-21 21:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 21:33 Petr Malat [this message]
2024-03-21 21:39 ` [PATCH] cgroup/cpuset: Make cpuset.cpus.effective independent of cpuset.cpus Petr Malat
2024-03-25 20:12   ` Tejun Heo
2024-03-26 15:14     ` Waiman Long
2024-03-26 16:17       ` Tejun Heo
2024-04-02 17:04   ` Michal Koutný
2024-04-04  4:36     ` Petr Malat
2024-04-04  8:09       ` Michal Koutný
2024-03-22  1:41 ` [RFC/POC]: " Waiman Long
2024-03-22  5:54   ` Petr Malat

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=Zfynj56eDdCSdIxv@ntb.petris.klfree.czf \
    --to=oss@malat.biz \
    --cc=cgroups@vger.kernel.org \
    --cc=longman@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).