From: Will Deacon <will@kernel.org> To: Valentin Schneider <valentin.schneider@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Marc Zyngier <maz@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Zijlstra <peterz@infradead.org>, Morten Rasmussen <morten.rasmussen@arm.com>, Qais Yousef <qais.yousef@arm.com>, Suren Baghdasaryan <surenb@google.com>, Quentin Perret <qperret@google.com>, Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, Ingo Molnar <mingo@redhat.com>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Daniel Bristot de Oliveira <bristot@redhat.com>, kernel-team@android.com Subject: Re: [PATCH v8 11/19] sched: Allow task CPU affinity to be restricted on asymmetric systems Date: Mon, 7 Jun 2021 23:52:03 +0100 [thread overview] Message-ID: <20210607225202.GB8215@willie-the-truck> (raw) In-Reply-To: <87zgw5d05b.mognet@arm.com> On Fri, Jun 04, 2021 at 06:12:32PM +0100, Valentin Schneider wrote: > On 02/06/21 17:47, Will Deacon wrote: > > +static int restrict_cpus_allowed_ptr(struct task_struct *p, > > + struct cpumask *new_mask, > > + const struct cpumask *subset_mask) > > +{ > > + struct rq_flags rf; > > + struct rq *rq; > > + int err; > > + struct cpumask *user_mask = NULL; > > + > > + if (!p->user_cpus_ptr) { > > + user_mask = kmalloc(cpumask_size(), GFP_KERNEL); > > + > > + if (!user_mask) > > + return -ENOMEM; > > + } > > + > > + rq = task_rq_lock(p, &rf); > > + > > + /* > > + * Forcefully restricting the affinity of a deadline task is > > + * likely to cause problems, so fail and noisily override the > > + * mask entirely. > > + */ > > + if (task_has_dl_policy(p) && dl_bandwidth_enabled()) { > > + err = -EPERM; > > + goto err_unlock; > > + } > > + > > + if (!cpumask_and(new_mask, &p->cpus_mask, subset_mask)) { > > + err = -EINVAL; > > + goto err_unlock; > > + } > > + > > + /* > > + * We're about to butcher the task affinity, so keep track of what > > + * the user asked for in case we're able to restore it later on. > > + */ > > + if (user_mask) { > > + cpumask_copy(user_mask, p->cpus_ptr); > > + p->user_cpus_ptr = user_mask; > > + } > > + > > Shouldn't that be done before any of the bailouts above, so we can > potentially restore the mask even if we end up forcefully expanding the > affinity? I don't think so. I deliberately only track the old mask if we've managed to take a subset for the 32-bit task. If we end up having to override the mask entirely, then I treat it the same way as an explicit affinity change (only with a warning printed) and don't then try to restore the old mask -- it feels like we'd be overriding the affinity twice if we tried to do that. > > + return __set_cpus_allowed_ptr_locked(p, new_mask, 0, rq, &rf); > > + > > +err_unlock: > > + task_rq_unlock(rq, p, &rf); > > + kfree(user_mask); > > + return err; > > +} > > + > > +/* > > + * Restrict the CPU affinity of task @p so that it is a subset of > > + * task_cpu_possible_mask() and point @p->user_cpu_ptr to a copy of the > > + * old affinity mask. If the resulting mask is empty, we warn and walk > > + * up the cpuset hierarchy until we find a suitable mask. > > + */ > > +void force_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + cpumask_var_t new_mask; > > + const struct cpumask *override_mask = task_cpu_possible_mask(p); > > + > > + alloc_cpumask_var(&new_mask, GFP_KERNEL); > > + > > + /* > > + * __migrate_task() can fail silently in the face of concurrent > > + * offlining of the chosen destination CPU, so take the hotplug > > + * lock to ensure that the migration succeeds. > > + */ > > + cpus_read_lock(); > > I'm thinking this might not be required with: > > http://lore.kernel.org/r/20210526205751.842360-3-valentin.schneider@arm.com > > but then again this isn't merged yet :-) Agreed, if that patch does what it says on the tin ;) I need to digest your reply to me, as this is mind-bending stuff. > > +static int > > +__sched_setaffinity(struct task_struct *p, const struct cpumask *mask); > > + > > +/* > > + * Restore the affinity of a task @p which was previously restricted by a > > + * call to force_compatible_cpus_allowed_ptr(). This will clear (and free) > > + * @p->user_cpus_ptr. > > + */ > > +void relax_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + unsigned long flags; > > + struct cpumask *mask = p->user_cpus_ptr; > > + > > + /* > > + * Try to restore the old affinity mask. If this fails, then > > + * we free the mask explicitly to avoid it being inherited across > > + * a subsequent fork(). > > + */ > > + if (!mask || !__sched_setaffinity(p, mask)) > > + return; > > + > > + raw_spin_lock_irqsave(&p->pi_lock, flags); > > + release_user_cpus_ptr(p); > > + raw_spin_unlock_irqrestore(&p->pi_lock, flags); > > AFAICT an affinity change can happen between __sched_setaffinity() and > reacquiring the ->pi_lock. Right now this can't be another > force_compatible_cpus_allowed_ptr() because this is only driven by > arch_setup_new_exec() against current, so we should be fine, but here be > dragons. That's a good point. I'll add a comment for now, since I'm not sure who else might end up using this in future. Generally it's pretty agnostic to how it's being used, but we're certainly relying on the serialisation of restrict/relax calls. Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: Valentin Schneider <valentin.schneider@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Marc Zyngier <maz@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Zijlstra <peterz@infradead.org>, Morten Rasmussen <morten.rasmussen@arm.com>, Qais Yousef <qais.yousef@arm.com>, Suren Baghdasaryan <surenb@google.com>, Quentin Perret <qperret@google.com>, Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, Ingo Molnar <mingo@redhat.com>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Daniel Bristot de Oliveira <bristot@redhat.com>, kernel-team@android.com Subject: Re: [PATCH v8 11/19] sched: Allow task CPU affinity to be restricted on asymmetric systems Date: Mon, 7 Jun 2021 23:52:03 +0100 [thread overview] Message-ID: <20210607225202.GB8215@willie-the-truck> (raw) In-Reply-To: <87zgw5d05b.mognet@arm.com> On Fri, Jun 04, 2021 at 06:12:32PM +0100, Valentin Schneider wrote: > On 02/06/21 17:47, Will Deacon wrote: > > +static int restrict_cpus_allowed_ptr(struct task_struct *p, > > + struct cpumask *new_mask, > > + const struct cpumask *subset_mask) > > +{ > > + struct rq_flags rf; > > + struct rq *rq; > > + int err; > > + struct cpumask *user_mask = NULL; > > + > > + if (!p->user_cpus_ptr) { > > + user_mask = kmalloc(cpumask_size(), GFP_KERNEL); > > + > > + if (!user_mask) > > + return -ENOMEM; > > + } > > + > > + rq = task_rq_lock(p, &rf); > > + > > + /* > > + * Forcefully restricting the affinity of a deadline task is > > + * likely to cause problems, so fail and noisily override the > > + * mask entirely. > > + */ > > + if (task_has_dl_policy(p) && dl_bandwidth_enabled()) { > > + err = -EPERM; > > + goto err_unlock; > > + } > > + > > + if (!cpumask_and(new_mask, &p->cpus_mask, subset_mask)) { > > + err = -EINVAL; > > + goto err_unlock; > > + } > > + > > + /* > > + * We're about to butcher the task affinity, so keep track of what > > + * the user asked for in case we're able to restore it later on. > > + */ > > + if (user_mask) { > > + cpumask_copy(user_mask, p->cpus_ptr); > > + p->user_cpus_ptr = user_mask; > > + } > > + > > Shouldn't that be done before any of the bailouts above, so we can > potentially restore the mask even if we end up forcefully expanding the > affinity? I don't think so. I deliberately only track the old mask if we've managed to take a subset for the 32-bit task. If we end up having to override the mask entirely, then I treat it the same way as an explicit affinity change (only with a warning printed) and don't then try to restore the old mask -- it feels like we'd be overriding the affinity twice if we tried to do that. > > + return __set_cpus_allowed_ptr_locked(p, new_mask, 0, rq, &rf); > > + > > +err_unlock: > > + task_rq_unlock(rq, p, &rf); > > + kfree(user_mask); > > + return err; > > +} > > + > > +/* > > + * Restrict the CPU affinity of task @p so that it is a subset of > > + * task_cpu_possible_mask() and point @p->user_cpu_ptr to a copy of the > > + * old affinity mask. If the resulting mask is empty, we warn and walk > > + * up the cpuset hierarchy until we find a suitable mask. > > + */ > > +void force_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + cpumask_var_t new_mask; > > + const struct cpumask *override_mask = task_cpu_possible_mask(p); > > + > > + alloc_cpumask_var(&new_mask, GFP_KERNEL); > > + > > + /* > > + * __migrate_task() can fail silently in the face of concurrent > > + * offlining of the chosen destination CPU, so take the hotplug > > + * lock to ensure that the migration succeeds. > > + */ > > + cpus_read_lock(); > > I'm thinking this might not be required with: > > http://lore.kernel.org/r/20210526205751.842360-3-valentin.schneider@arm.com > > but then again this isn't merged yet :-) Agreed, if that patch does what it says on the tin ;) I need to digest your reply to me, as this is mind-bending stuff. > > +static int > > +__sched_setaffinity(struct task_struct *p, const struct cpumask *mask); > > + > > +/* > > + * Restore the affinity of a task @p which was previously restricted by a > > + * call to force_compatible_cpus_allowed_ptr(). This will clear (and free) > > + * @p->user_cpus_ptr. > > + */ > > +void relax_compatible_cpus_allowed_ptr(struct task_struct *p) > > +{ > > + unsigned long flags; > > + struct cpumask *mask = p->user_cpus_ptr; > > + > > + /* > > + * Try to restore the old affinity mask. If this fails, then > > + * we free the mask explicitly to avoid it being inherited across > > + * a subsequent fork(). > > + */ > > + if (!mask || !__sched_setaffinity(p, mask)) > > + return; > > + > > + raw_spin_lock_irqsave(&p->pi_lock, flags); > > + release_user_cpus_ptr(p); > > + raw_spin_unlock_irqrestore(&p->pi_lock, flags); > > AFAICT an affinity change can happen between __sched_setaffinity() and > reacquiring the ->pi_lock. Right now this can't be another > force_compatible_cpus_allowed_ptr() because this is only driven by > arch_setup_new_exec() against current, so we should be fine, but here be > dragons. That's a good point. I'll add a comment for now, since I'm not sure who else might end up using this in future. Generally it's pretty agnostic to how it's being used, but we're certainly relying on the serialisation of restrict/relax calls. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-07 22:52 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-02 16:47 [PATCH v8 00/19] Add support for 32-bit tasks on asymmetric AArch32 systems Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 01/19] arm64: cpuinfo: Split AArch32 registers out into a separate struct Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-03 12:38 ` Mark Rutland 2021-06-03 12:38 ` Mark Rutland 2021-06-03 17:24 ` Will Deacon 2021-06-03 17:24 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 02/19] arm64: Allow mismatched 32-bit EL0 support Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-03 12:37 ` Mark Rutland 2021-06-03 12:37 ` Mark Rutland 2021-06-03 17:44 ` Will Deacon 2021-06-03 17:44 ` Will Deacon 2021-06-04 9:38 ` Mark Rutland 2021-06-04 9:38 ` Mark Rutland 2021-06-04 11:05 ` Will Deacon 2021-06-04 11:05 ` Will Deacon 2021-06-04 12:04 ` Mark Rutland 2021-06-04 12:04 ` Mark Rutland 2021-06-04 13:50 ` Will Deacon 2021-06-04 13:50 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 03/19] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched " Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 04/19] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 05/19] sched: Introduce task_cpu_possible_mask() to limit fallback rq selection Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:10 ` Valentin Schneider 2021-06-04 17:10 ` Valentin Schneider 2021-06-07 17:04 ` Will Deacon 2021-06-07 17:04 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 06/19] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:11 ` Valentin Schneider 2021-06-04 17:11 ` Valentin Schneider 2021-06-07 17:20 ` Will Deacon 2021-06-07 17:20 ` Will Deacon 2021-06-10 10:20 ` Valentin Schneider 2021-06-10 10:20 ` Valentin Schneider 2021-06-02 16:47 ` [PATCH v8 07/19] cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus() Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:11 ` Valentin Schneider 2021-06-04 17:11 ` Valentin Schneider 2021-06-02 16:47 ` [PATCH v8 08/19] sched: Reject CPU affinity changes based on task_cpu_possible_mask() Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:11 ` Valentin Schneider 2021-06-04 17:11 ` Valentin Schneider 2021-06-07 22:43 ` Will Deacon 2021-06-07 22:43 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 09/19] sched: Introduce task_struct::user_cpus_ptr to track requested affinity Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:12 ` Valentin Schneider 2021-06-04 17:12 ` Valentin Schneider 2021-06-02 16:47 ` [PATCH v8 10/19] sched: Split the guts of sched_setaffinity() into a helper function Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:12 ` Valentin Schneider 2021-06-04 17:12 ` Valentin Schneider 2021-06-02 16:47 ` [PATCH v8 11/19] sched: Allow task CPU affinity to be restricted on asymmetric systems Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-04 17:12 ` Valentin Schneider 2021-06-04 17:12 ` Valentin Schneider 2021-06-07 22:52 ` Will Deacon [this message] 2021-06-07 22:52 ` Will Deacon 2021-06-10 10:20 ` Valentin Schneider 2021-06-10 10:20 ` Valentin Schneider 2021-06-02 16:47 ` [PATCH v8 12/19] sched: Introduce task_cpus_dl_admissible() to check proposed affinity Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-03 9:43 ` Daniel Bristot de Oliveira 2021-06-03 9:43 ` Daniel Bristot de Oliveira 2021-06-03 9:52 ` Will Deacon 2021-06-03 9:52 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 13/19] arm64: Implement task_cpu_possible_mask() Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 14/19] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-03 9:45 ` Daniel Bristot de Oliveira 2021-06-03 9:45 ` Daniel Bristot de Oliveira 2021-06-02 16:47 ` [PATCH v8 15/19] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-03 12:58 ` Mark Rutland 2021-06-03 12:58 ` Mark Rutland 2021-06-03 17:40 ` Will Deacon 2021-06-03 17:40 ` Will Deacon 2021-06-04 9:49 ` Mark Rutland 2021-06-04 9:49 ` Mark Rutland 2021-06-04 12:14 ` Qais Yousef 2021-06-04 12:14 ` Qais Yousef 2021-06-02 16:47 ` [PATCH v8 16/19] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 17/19] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 18/19] arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores Will Deacon 2021-06-02 16:47 ` Will Deacon 2021-06-02 16:47 ` [PATCH v8 19/19] Documentation: arm64: describe asymmetric 32-bit support Will Deacon 2021-06-02 16:47 ` Will Deacon
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=20210607225202.GB8215@willie-the-truck \ --to=will@kernel.org \ --cc=bristot@redhat.com \ --cc=catalin.marinas@arm.com \ --cc=dietmar.eggemann@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=hannes@cmpxchg.org \ --cc=juri.lelli@redhat.com \ --cc=kernel-team@android.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maz@kernel.org \ --cc=mingo@redhat.com \ --cc=morten.rasmussen@arm.com \ --cc=peterz@infradead.org \ --cc=qais.yousef@arm.com \ --cc=qperret@google.com \ --cc=rjw@rjwysocki.net \ --cc=surenb@google.com \ --cc=tj@kernel.org \ --cc=valentin.schneider@arm.com \ --cc=vincent.guittot@linaro.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: linkBe 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.