All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Alex Belits <abelits@marvell.com>, Nitesh Lal <nilal@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Nicolas Saenz <nsaenzju@redhat.com>,
	Christoph Lameter <cl@gentwo.de>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Zefan Li <lizefan.x@bytedance.com>,
	cgroups@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset
Date: Fri, 16 Jul 2021 14:02:50 -0400	[thread overview]
Message-ID: <8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com> (raw)
In-Reply-To: <20210714135420.69624-1-frederic@kernel.org>

On 7/14/21 9:54 AM, Frederic Weisbecker wrote:
> The fact that "isolcpus=" behaviour can't be modified at runtime is an
> eternal source of discussion and debate opposing a useful feature against
> a terrible interface.
>
> I've long since tried to figure out a proper way to control this at
> runtime using cpusets, which isn't easy as a boot time single cpumask
> is difficult to map to a hierarchy of cpusets that can even overlap.

I have a cpuset patch that allow disabling of load balancing in a 
cgroup-v2 setting:

https://lore.kernel.org/lkml/20210621184924.27493-1-longman@redhat.com/

The idea of cpuset partition is that there will be no overlap of cpus in 
different partitions. So there will be no confusion whether a cpu is 
load-balanced or not.

>
> The idea here is to map the boot-set isolation behaviour to any cpuset
> directory whose cpumask is a subset of "isolcpus=". I let you browse
> for details on the last patch.
>
> Note this is still WIP and half-baked, but I figured it's important to
> validate the interface early.

Using different cpumasks for different isolated properties is the easy 
part. The hard part is to make different subsystems to change their 
behavior as the isolation masks change dynamically at run time. 
Currently, they check the housekeeping cpumask only at boot time or when 
certain events happen.

Cheers,
Longman



WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <llong-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Frederic Weisbecker
	<frederic-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Alex Belits <abelits-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Nitesh Lal <nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Nicolas Saenz <nsaenzju-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Christoph Lameter <cl-LoxgEY9JZOazQB+pC5nmwQ@public.gmane.org>,
	Marcelo Tosatti
	<mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset
Date: Fri, 16 Jul 2021 14:02:50 -0400	[thread overview]
Message-ID: <8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com> (raw)
In-Reply-To: <20210714135420.69624-1-frederic-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

On 7/14/21 9:54 AM, Frederic Weisbecker wrote:
> The fact that "isolcpus=" behaviour can't be modified at runtime is an
> eternal source of discussion and debate opposing a useful feature against
> a terrible interface.
>
> I've long since tried to figure out a proper way to control this at
> runtime using cpusets, which isn't easy as a boot time single cpumask
> is difficult to map to a hierarchy of cpusets that can even overlap.

I have a cpuset patch that allow disabling of load balancing in a 
cgroup-v2 setting:

https://lore.kernel.org/lkml/20210621184924.27493-1-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org/

The idea of cpuset partition is that there will be no overlap of cpus in 
different partitions. So there will be no confusion whether a cpu is 
load-balanced or not.

>
> The idea here is to map the boot-set isolation behaviour to any cpuset
> directory whose cpumask is a subset of "isolcpus=". I let you browse
> for details on the last patch.
>
> Note this is still WIP and half-baked, but I figured it's important to
> validate the interface early.

Using different cpumasks for different isolated properties is the easy 
part. The hard part is to make different subsystems to change their 
behavior as the isolation masks change dynamically at run time. 
Currently, they check the housekeeping cpumask only at boot time or when 
certain events happen.

Cheers,
Longman



  parent reply	other threads:[~2021-07-16 18:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 13:54 [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Frederic Weisbecker
2021-07-14 13:54 ` Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 1/6] pci: Decouple HK_FLAG_WQ and HK_FLAG_DOMAIN cpumask fetch Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 2/6] workqueue: " Frederic Weisbecker
2021-07-14 13:54   ` Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 3/6] net: " Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 4/6] sched/isolation: Split domain housekeeping mask from the rest Frederic Weisbecker
2021-07-14 13:54   ` Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 5/6] sched/isolation: Make HK_FLAG_DOMAIN mutable Frederic Weisbecker
2021-07-14 13:54   ` Frederic Weisbecker
2021-07-21 14:28   ` Vincent Donnefort
2021-07-14 13:54 ` [RFC PATCH 6/6] cpuset: Add cpuset.isolation_mask file Frederic Weisbecker
2021-07-14 13:54   ` Frederic Weisbecker
2021-07-14 16:31   ` Marcelo Tosatti
2021-07-19 13:26     ` Frederic Weisbecker
2021-07-19 13:26       ` Frederic Weisbecker
2021-07-19 15:41       ` Marcelo Tosatti
2021-07-19 15:41         ` Marcelo Tosatti
2021-07-14 16:52   ` Peter Zijlstra
2021-07-14 16:52     ` Peter Zijlstra
2021-07-14 23:13     ` Frederic Weisbecker
2021-07-14 23:13       ` Frederic Weisbecker
2021-07-14 23:44       ` Valentin Schneider
2021-07-14 23:44         ` Valentin Schneider
2021-07-15  0:07         ` Frederic Weisbecker
2021-07-15  0:07           ` Frederic Weisbecker
2021-07-15  9:04       ` Peter Zijlstra
2021-07-15  9:04         ` Peter Zijlstra
2021-07-19 13:17         ` Frederic Weisbecker
2021-07-19 13:17           ` Frederic Weisbecker
2021-07-16 18:02 ` Waiman Long [this message]
2021-07-16 18:02   ` [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Waiman Long
2021-07-19 13:57   ` Frederic Weisbecker
2021-07-19 13:57     ` Frederic Weisbecker

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=8ea7a78f-948e-75e8-1c4f-59b349c858f6@redhat.com \
    --to=llong@redhat.com \
    --cc=abelits@marvell.com \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@gentwo.de \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mtosatti@redhat.com \
    --cc=nilal@redhat.com \
    --cc=nsaenzju@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 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.