Re: [PATCH 0/6] An alternative series for asymmetric AArch32 systems

From: Will Deacon <will@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Qais Yousef <qais.yousef@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Elliott Hughes <enh@google.com>,
	kernel-team <kernel-team@android.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/6] An alternative series for asymmetric AArch32 systems
Date: Thu, 29 Oct 2020 22:17:48 +0000	[thread overview]
Message-ID: <20201029221747.GC31375@willie-the-truck> (raw)
In-Reply-To: <CAJuCfpH2vZfH0mZMxukKvcs1jW7Udiu4P-5z4ZyDU1-JN3xMdg@mail.gmail.com>

Hi Suren,

On Thu, Oct 29, 2020 at 11:42:04AM -0700, Suren Baghdasaryan wrote:
> On Tue, Oct 27, 2020 at 2:51 PM Will Deacon <will@kernel.org> wrote:
> > I was playing around with the asymmetric AArch32 RFCv2 from Qais:
> >
> > https://lore.kernel.org/r/20201021104611.2744565-1-qais.yousef@arm.com
> >
> > and ended up writing my own implementation this afternoon. I think it's
> > smaller, simpler and easier to work with. In particular:
> >
> >   * I got rid of the sysctl in favour of a plain cmdline parameter
> >   * I don't have a new CPU capability
> >   * I don't have a new thread flag
> >   * I expose a cpumask to userspace via sysfs to identify the 32-bit CPUs
> >
> > Anyway, I don't think we should merge this stuff (other than the first patch)
> > until we've figured out what's going on in Android, but I wanted to get
> > this out as something which we might be able to build on.
> 
> Thanks for posting this series. Just to provide some more background,
> on Android, 64-bit apps are forked from zygote64 process and 32-bit
> ones from zygote. So normally we could handle the issues with such
> asymmetric architectures using cpuset cgroup and placing zygote
> process (and consequently all its children) in a separate cgroup with
> affinity mask that includes only 32-bit capable cores. We would have
> to take care of the affinity mask for such tasks during task
> migrations, but it's still doable from userspace. However there are
> 64-bit apps which fork 32-bit processes and that is the case which is
> unclear how to handle without help from the kernel. Still discussing
> possible solutions. CC'ing more people from Android to be in the loop.

Thanks for joining in and adding others. Perhaps one thing we could do
on top of this series is to restrict the affinity mask when execve()ing
a 32-bit application. The major problem I have with that is that it
goes directly against the man page for sched_setaffinity(), which states:

  | A child created via fork(2) inherits its parent's CPU affinity mask.
  | The affinity mask is preserved across an execve(2)

so there's a risk of regression if applications rely on the mask being
preserved.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel