From: Marc Zyngier <maz@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.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>, kernel-team@android.com Subject: Re: [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Date: Tue, 10 Nov 2020 10:46:37 +0000 [thread overview] Message-ID: <93df8d6ed8842b83d76fa57ad1ef5bb4@kernel.org> (raw) In-Reply-To: <X6pnFgD5NT9smHG5@kroah.com> On 2020-11-10 10:10, Greg Kroah-Hartman wrote: > On Tue, Nov 10, 2020 at 09:53:53AM +0000, Marc Zyngier wrote: >> On 2020-11-10 09:36, Greg Kroah-Hartman wrote: >> >> [...] >> >> > While punting the logic out to userspace is simple for the kernel, and >> > of course my first option, I think this isn't going to work in the >> > long-run and the kernel will have to "know" what type of process it is >> > scheduling in order to correctly deal with this nightmare as userspace >> > can't do that well, if at all. >> >> For that to happen, we must first decide which part of the userspace >> ABI we are prepared to compromise on. The most obvious one would be to >> allow overriding the affinity on exec, but I'm pretty sure it has bad >> interactions with cgroups, on top of violating the existing ABI which >> mandates that the affinity is inherited across exec. > > So you are saying that you have to violate this today with this patch > set? Or would have to violate that if the scheduler got involved? Doing nothing (as with this series) doesn't result in an ABI breakage. It "only" results in an unreliable system. If you start making decisions behind userspace's back for the sake of making things reliable (which is a commendable goal), you break the ABI. Rock, please meet A Hard Place. And that's the real issue: there is no good solution to this problem. Only a different set of ugly compromises. > How is userspace going to "know" how to do all of this properly? Who > is > going to write that code? > >> There may be other options (always make at least one 32bit-capable CPU >> part of the process affinity?), but they all imply some form of >> userspace >> visible regressions. >> >> Pick your poison... :-/ > > What do the system designers and users of this hardware recommend? > They > are the ones that dreamed up this, and seem to somehow want this. What > do they think the correct solution is here as obviously they must have > thought this through when designing such a beast, right? > > And if they didn't think any of this through then why are they wanting > to run Linux on this thing? At this stage, I'll reach out for some Bombay mix (I dislike pop corn). M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-arch@vger.kernel.org, kernel-team@android.com, Quentin Perret <qperret@google.com>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Qais Yousef <qais.yousef@arm.com>, Suren Baghdasaryan <surenb@google.com>, Will Deacon <will@kernel.org>, Morten Rasmussen <morten.rasmussen@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Date: Tue, 10 Nov 2020 10:46:37 +0000 [thread overview] Message-ID: <93df8d6ed8842b83d76fa57ad1ef5bb4@kernel.org> (raw) In-Reply-To: <X6pnFgD5NT9smHG5@kroah.com> On 2020-11-10 10:10, Greg Kroah-Hartman wrote: > On Tue, Nov 10, 2020 at 09:53:53AM +0000, Marc Zyngier wrote: >> On 2020-11-10 09:36, Greg Kroah-Hartman wrote: >> >> [...] >> >> > While punting the logic out to userspace is simple for the kernel, and >> > of course my first option, I think this isn't going to work in the >> > long-run and the kernel will have to "know" what type of process it is >> > scheduling in order to correctly deal with this nightmare as userspace >> > can't do that well, if at all. >> >> For that to happen, we must first decide which part of the userspace >> ABI we are prepared to compromise on. The most obvious one would be to >> allow overriding the affinity on exec, but I'm pretty sure it has bad >> interactions with cgroups, on top of violating the existing ABI which >> mandates that the affinity is inherited across exec. > > So you are saying that you have to violate this today with this patch > set? Or would have to violate that if the scheduler got involved? Doing nothing (as with this series) doesn't result in an ABI breakage. It "only" results in an unreliable system. If you start making decisions behind userspace's back for the sake of making things reliable (which is a commendable goal), you break the ABI. Rock, please meet A Hard Place. And that's the real issue: there is no good solution to this problem. Only a different set of ugly compromises. > How is userspace going to "know" how to do all of this properly? Who > is > going to write that code? > >> There may be other options (always make at least one 32bit-capable CPU >> part of the process affinity?), but they all imply some form of >> userspace >> visible regressions. >> >> Pick your poison... :-/ > > What do the system designers and users of this hardware recommend? > They > are the ones that dreamed up this, and seem to somehow want this. What > do they think the correct solution is here as obviously they must have > thought this through when designing such a beast, right? > > And if they didn't think any of this through then why are they wanting > to run Linux on this thing? At this stage, I'll reach out for some Bombay mix (I dislike pop corn). M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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:[~2020-11-10 10:46 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-09 21:30 [PATCH v2 0/6] An alternative series for asymmetric AArch32 systems Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-09 21:30 ` [PATCH v2 1/6] arm64: cpuinfo: Split AArch32 registers out into a separate struct Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-09 21:30 ` [PATCH v2 2/6] arm64: Allow mismatched 32-bit EL0 support Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-11 19:10 ` Catalin Marinas 2020-11-11 19:10 ` Catalin Marinas 2020-11-13 9:36 ` Will Deacon 2020-11-13 9:36 ` Will Deacon 2020-11-13 10:26 ` Catalin Marinas 2020-11-13 10:26 ` Catalin Marinas 2020-11-09 21:30 ` [PATCH v2 3/6] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched " Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-10 9:33 ` Marc Zyngier 2020-11-10 9:33 ` Marc Zyngier 2020-11-09 21:30 ` [PATCH v2 4/6] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-09 21:30 ` [PATCH v2 5/6] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon 2020-11-09 21:30 ` Will Deacon 2020-11-10 7:04 ` Greg Kroah-Hartman 2020-11-10 7:04 ` Greg Kroah-Hartman 2020-11-10 9:28 ` Catalin Marinas 2020-11-10 9:28 ` Catalin Marinas 2020-11-10 9:36 ` Greg Kroah-Hartman 2020-11-10 9:36 ` Greg Kroah-Hartman 2020-11-10 9:53 ` Marc Zyngier 2020-11-10 9:53 ` Marc Zyngier 2020-11-10 10:10 ` Greg Kroah-Hartman 2020-11-10 10:10 ` Greg Kroah-Hartman 2020-11-10 10:46 ` Marc Zyngier [this message] 2020-11-10 10:46 ` Marc Zyngier 2020-11-10 10:57 ` Catalin Marinas 2020-11-10 10:57 ` Catalin Marinas 2020-11-09 21:30 ` [PATCH v2 6/6] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon 2020-11-09 21:30 ` 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=93df8d6ed8842b83d76fa57ad1ef5bb4@kernel.org \ --to=maz@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=kernel-team@android.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=morten.rasmussen@arm.com \ --cc=peterz@infradead.org \ --cc=qais.yousef@arm.com \ --cc=qperret@google.com \ --cc=surenb@google.com \ --cc=will@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: 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.