From: Juri Lelli <firstname.lastname@example.org> To: Quentin Perret <email@example.com> Cc: Will Deacon <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, Catalin Marinas <firstname.lastname@example.org>, Marc Zyngier <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Morten Rasmussen <firstname.lastname@example.org>, Qais Yousef <email@example.com>, Suren Baghdasaryan <firstname.lastname@example.org>, Tejun Heo <email@example.com>, Johannes Weiner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Vincent Guittot <firstname.lastname@example.org>, "Rafael J. Wysocki" <email@example.com>, firstname.lastname@example.org, Daniel Bristot de Oliveira <email@example.com> Subject: Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Date: Thu, 20 May 2021 11:13:39 +0200 [thread overview] Message-ID: <YKYoQ0ezahSC/RAg@localhost.localdomain> (raw) In-Reply-To: <YKO+9lPLQLPm4Nwt@google.com> Hi Quentin and Will, Apologies for the delay in replying. On 18/05/21 13:19, Quentin Perret wrote: > On Tuesday 18 May 2021 at 11:59:51 (+0100), Will Deacon wrote: > > On Tue, May 18, 2021 at 10:48:07AM +0000, Quentin Perret wrote: > > > On Tuesday 18 May 2021 at 11:28:34 (+0100), Will Deacon wrote: > > > > I don't have strong opinions on this, but I _do_ want the admission via > > > > sched_setattr() to be consistent with execve(). What you're suggesting > > > > ticks that box, but how many applications are prepared to handle a failed > > > > execve()? I suspect it will be fatal. > > > > > > Yep, probably. > > > > > > > Probably also worth pointing out that the approach here will at least > > > > warn in the execve() case when the affinity is overridden for a deadline > > > > task. > > > > > > Right so I think either way will be imperfect, so I agree with the > > > above. > > > > > > Maybe one thing though is that, IIRC, userspace _can_ disable admission > > > control if it wants to. In this case I'd have no problem with allowing > > > this weird behaviour when admission control is off -- the kernel won't > > > provide any guarantees. But if it's left on, then it's a different > > > story. > > > > > > So what about we say, if admission control is off, we allow execve() and > > > sched_setattr() with appropriate warnings as you suggest, but if > > > admission control is on then we fail both? > > > > That's an interesting idea. The part that I'm not super keen about is > > that it means admission control _also_ has an effect on the behaviour of > > execve() > > Right, that's a good point. And it looks like fork() behaves the same > regardless of admission control being enabled or not -- it is forbidden > from DL either way. So I can't say there is a precedent :/ > > > so practically you'd have to have it disabled as long as you > > have the possibility of 32-bit deadline tasks anywhere in the system, > > which impacts 64-bit tasks which may well want admission control enabled. > > Indeed, this is a bit sad, but I don't know if the kernel should pretend > it can guarantee to meet your deadlines and at the same time allow to do > something that wrecks the underlying theory. > > I'd personally be happy with saying that admission control should be > disabled on these dumb systems (and have that documented), at least > until DL gets proper support for affinities. ISTR there was work going > in that direction, but some folks in the CC list will know better. > > @Juri, maybe you would know if that's still planned? I won't go as far as saying planned, but that is still under "our" radar for sure. Daniel was working on it, but I don't think he had any time to resume that bit of work lately. So, until we have that, I think we have been as conservative as we could for this type of decisions. I'm a little afraid that allowing configuration to break admission control (even with a non fatal warning is emitted) is still risky. I'd go with fail hard if AC is on, let it pass if AC is off (supposedly the user knows what to do). But I'm not familiar with the mixed 32/64 apps usecase you describe, so I might be missing details. Best, Juri _______________________________________________ linux-arm-kernel mailing list firstname.lastname@example.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-20 9:17 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-18 9:47 [PATCH v6 00/21] Add support for 32-bit tasks on asymmetric AArch32 systems Will Deacon 2021-05-18 9:47 ` [PATCH v6 01/21] arm64: cpuinfo: Split AArch32 registers out into a separate struct Will Deacon 2021-05-21 10:47 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 02/21] arm64: Allow mismatched 32-bit EL0 support Will Deacon 2021-05-21 10:25 ` Catalin Marinas 2021-05-24 12:05 ` Will Deacon 2021-05-24 13:49 ` Catalin Marinas 2021-05-21 10:41 ` Catalin Marinas 2021-05-24 12:09 ` Will Deacon 2021-05-24 13:46 ` Catalin Marinas 2021-05-21 15:22 ` Qais Yousef 2021-05-24 20:21 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 03/21] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched " Will Deacon 2021-05-21 10:47 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 04/21] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Will Deacon 2021-05-21 10:55 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 05/21] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon 2021-05-21 11:00 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 06/21] sched: Introduce task_cpu_possible_mask() to limit fallback rq selection Will Deacon 2021-05-21 16:03 ` Peter Zijlstra 2021-05-24 12:17 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 07/21] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Will Deacon 2021-05-21 17:39 ` Qais Yousef 2021-05-24 20:21 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 08/21] cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus() Will Deacon 2021-05-21 16:25 ` Qais Yousef 2021-05-24 21:09 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 09/21] sched: Reject CPU affinity changes based on task_cpu_possible_mask() Will Deacon 2021-05-18 9:47 ` [PATCH v6 10/21] sched: Introduce task_struct::user_cpus_ptr to track requested affinity Will Deacon 2021-05-18 9:47 ` [PATCH v6 11/21] sched: Split the guts of sched_setaffinity() into a helper function Will Deacon 2021-05-21 16:41 ` Qais Yousef 2021-05-24 21:16 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 12/21] sched: Allow task CPU affinity to be restricted on asymmetric systems Will Deacon 2021-05-21 17:11 ` Qais Yousef 2021-05-24 21:43 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Will Deacon 2021-05-18 10:20 ` Quentin Perret 2021-05-18 10:28 ` Will Deacon 2021-05-18 10:48 ` Quentin Perret 2021-05-18 10:59 ` Will Deacon 2021-05-18 13:19 ` Quentin Perret 2021-05-20 9:13 ` Juri Lelli [this message] 2021-05-20 10:16 ` Will Deacon 2021-05-20 10:33 ` Quentin Perret 2021-05-20 12:38 ` Juri Lelli 2021-05-20 12:38 ` Daniel Bristot de Oliveira 2021-05-20 15:06 ` Dietmar Eggemann 2021-05-20 16:00 ` Daniel Bristot de Oliveira 2021-05-20 17:55 ` Dietmar Eggemann 2021-05-20 18:03 ` Will Deacon 2021-05-21 11:26 ` Dietmar Eggemann 2021-05-20 18:01 ` Will Deacon 2021-05-21 5:25 ` Juri Lelli 2021-05-21 8:15 ` Quentin Perret 2021-05-21 8:39 ` Juri Lelli 2021-05-21 10:37 ` Will Deacon 2021-05-21 11:23 ` Dietmar Eggemann 2021-05-21 13:02 ` Quentin Perret 2021-05-21 14:04 ` Juri Lelli 2021-05-21 17:47 ` Dietmar Eggemann 2021-05-21 13:00 ` Daniel Bristot de Oliveira 2021-05-21 13:12 ` Quentin Perret 2021-05-24 20:47 ` Will Deacon 2021-05-18 9:47 ` [PATCH v6 14/21] freezer: Add frozen_or_skipped() helper function Will Deacon 2021-05-18 9:47 ` [PATCH v6 15/21] sched: Defer wakeup in ttwu() for unschedulable frozen tasks Will Deacon 2021-05-18 9:47 ` [PATCH v6 16/21] arm64: Implement task_cpu_possible_mask() Will Deacon 2021-05-24 14:57 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 17/21] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 Will Deacon 2021-05-24 15:02 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 18/21] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system Will Deacon 2021-05-24 15:46 ` Catalin Marinas 2021-05-24 20:32 ` Will Deacon 2021-05-25 9:43 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 19/21] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon 2021-05-24 15:47 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 20/21] arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores Will Deacon 2021-05-24 15:47 ` Catalin Marinas 2021-05-18 9:47 ` [PATCH v6 21/21] Documentation: arm64: describe asymmetric 32-bit support Will Deacon 2021-05-21 17:37 ` Qais Yousef 2021-05-24 21:46 ` Will Deacon 2021-05-24 16:22 ` Catalin Marinas 2021-05-21 17:45 ` [PATCH v6 00/21] Add support for 32-bit tasks on asymmetric AArch32 systems Qais Yousef 2021-05-24 22:08 ` 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=YKYoQ0ezahSC/RAg@localhost.localdomain \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE' \ /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
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 NNTP newsgroup(s).