All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Valentin Schneider
	<valentin.schneider-5wv7dgnIgG8@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: [regression] cpuset: offlined CPUs removed from affinity masks
Date: Wed, 19 Feb 2020 11:08:39 -0500 (EST)	[thread overview]
Message-ID: <1358308409.804.1582128519523.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20200219155202.GE698990-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>

----- On Feb 19, 2020, at 10:52 AM, Tejun Heo tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org wrote:

> On Wed, Feb 19, 2020 at 10:50:35AM -0500, Mathieu Desnoyers wrote:
>> I can look into figuring out the commit introducing this issue, which I
>> suspect will be close to the introduction of CONFIG_CPUSET into the
>> kernel (which was ages ago). I'll check and let you know.
> 
> Oh, yeah, I'm pretty sure it goes way back. I don't think tracking
> that down would be necessary. I was just wondering whether it was a
> recent change because you said it was a regression.

It's most likely not a recent regression, but it has unfortunate effects
on the affinity mask which directly affects my ongoing work on the
pin_on_cpu() system call [1].

The sched_setaffinity vs cpu hotplug semantic provided by CONFIG_CPUSET=n
if fine for the needs on pin_on_cpu(): when a CPU comes back online,
those reappear in the affinity mask, but it is not the case with
CONFIG_CPUSET=y.

I wonder if applying the online cpu masks to the per-thread affinity mask
is the correct approach ? I suspect what we may be looking for here is to keep
the affinity mask independent of cpu hotplug, and look-up both the per-thread
affinity mask and the online cpu mask whenever the scheduler needs to perform
"is_cpu_allowed()" to check task placement.

Then whenever sched_getaffinity or cpusets try to query the current set of
cpus on which a task can run right now, it could also look at both the task's
affinity mask and the online cpu mask.

Thanks,

Mathieu

[1] https://lore.kernel.org/r/20200121160312.26545-1-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>, cgroups <cgroups@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [regression] cpuset: offlined CPUs removed from affinity masks
Date: Wed, 19 Feb 2020 11:08:39 -0500 (EST)	[thread overview]
Message-ID: <1358308409.804.1582128519523.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20200219155202.GE698990@mtj.thefacebook.com>

----- On Feb 19, 2020, at 10:52 AM, Tejun Heo tj@kernel.org wrote:

> On Wed, Feb 19, 2020 at 10:50:35AM -0500, Mathieu Desnoyers wrote:
>> I can look into figuring out the commit introducing this issue, which I
>> suspect will be close to the introduction of CONFIG_CPUSET into the
>> kernel (which was ages ago). I'll check and let you know.
> 
> Oh, yeah, I'm pretty sure it goes way back. I don't think tracking
> that down would be necessary. I was just wondering whether it was a
> recent change because you said it was a regression.

It's most likely not a recent regression, but it has unfortunate effects
on the affinity mask which directly affects my ongoing work on the
pin_on_cpu() system call [1].

The sched_setaffinity vs cpu hotplug semantic provided by CONFIG_CPUSET=n
if fine for the needs on pin_on_cpu(): when a CPU comes back online,
those reappear in the affinity mask, but it is not the case with
CONFIG_CPUSET=y.

I wonder if applying the online cpu masks to the per-thread affinity mask
is the correct approach ? I suspect what we may be looking for here is to keep
the affinity mask independent of cpu hotplug, and look-up both the per-thread
affinity mask and the online cpu mask whenever the scheduler needs to perform
"is_cpu_allowed()" to check task placement.

Then whenever sched_getaffinity or cpusets try to query the current set of
cpus on which a task can run right now, it could also look at both the task's
affinity mask and the online cpu mask.

Thanks,

Mathieu

[1] https://lore.kernel.org/r/20200121160312.26545-1-mathieu.desnoyers@efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  parent reply	other threads:[~2020-02-19 16:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 17:41 [regression] cpuset: offlined CPUs removed from affinity masks Mathieu Desnoyers
2020-01-16 18:27 ` Valentin Schneider
     [not found] ` <1251528473.590671.1579196495905.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2020-02-17 16:03   ` Mathieu Desnoyers
2020-02-17 16:03     ` Mathieu Desnoyers
2020-02-19 15:19     ` Tejun Heo
     [not found]       ` <20200219151922.GB698990-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-19 15:43         ` Mathieu Desnoyers
2020-02-19 15:43           ` Mathieu Desnoyers
2020-02-19 15:47           ` Tejun Heo
     [not found]             ` <20200219154740.GD698990-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-19 15:50               ` Mathieu Desnoyers
2020-02-19 15:50                 ` Mathieu Desnoyers
2020-02-19 15:52                 ` Tejun Heo
     [not found]                   ` <20200219155202.GE698990-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-19 16:08                     ` Mathieu Desnoyers [this message]
2020-02-19 16:08                       ` Mathieu Desnoyers
     [not found]                       ` <1358308409.804.1582128519523.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2020-02-19 16:12                         ` Tejun Heo
2020-02-19 16:12                           ` Tejun Heo
     [not found]                           ` <20200219161222.GF698990-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-03-07 16:06                             ` Mathieu Desnoyers
2020-03-07 16:06                               ` Mathieu Desnoyers
     [not found]                               ` <316507033.21078.1583597207356.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2020-03-12 18:26                                 ` Tejun Heo
2020-03-12 18:26                                   ` Tejun Heo
     [not found]                                   ` <20200312182618.GE79873-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2020-03-12 19:47                                     ` Mathieu Desnoyers
2020-03-12 19:47                                       ` Mathieu Desnoyers
     [not found]                                       ` <1289608777.27165.1584042470528.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2020-03-24 18:01                                         ` Tejun Heo
2020-03-24 18:01                                           ` Tejun Heo
     [not found]                                           ` <20200324180139.GB162390-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2020-03-24 19:30                                             ` Mathieu Desnoyers
2020-03-24 19:30                                               ` Mathieu Desnoyers
     [not found]                                               ` <195391080.10219.1585078246788.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2020-03-30 19:53                                                 ` Mathieu Desnoyers
2020-03-30 19:53                                                   ` Mathieu Desnoyers

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=1358308409.804.1582128519523.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers-vg+e7yoek/dwk0htik3j/w@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=valentin.schneider-5wv7dgnIgG8@public.gmane.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.