On Fri, Oct 09, 2020 at 12:31:56PM +0100, Qais Yousef wrote: > On 10/09/20 10:33, Catalin Marinas wrote: > > On Fri, Oct 09, 2020 at 09:31:47AM +0100, Will Deacon wrote: > > > Honestly, I don't understand why we're trying to hide this asymmetry from > > > userspace by playing games with affinity masks in the kernel. Userspace > > > is likely to want to move things about _anyway_ because even amongst the > > > 32-bit capable cores, you may well have different clock frequencies to > > > contend with. > > > > > > So I'd be *much* happier to let the schesduler do its thing, and if one > > > of these 32-bit tasks ends up on a core that can't deal with it, then > > > tough, it gets killed. Give userspace the information it needs to avoid > > > that happening in the first place, rather than implicitly limit the mask. > > > > > > That way, the kernel support really boils down to two parts: > > > > > > 1. Remove the sanity checks we have to prevent 32-bit applications running > > > on asymmetric systems > > > > > > 2. Tell userspace about the problem > > > > This works for me as well as long as it is default off with a knob to > > turn it on. I'd prefer a sysctl (which can be driven from the command > > line in recent kernels IIRC) so that one can play with it a run-time. > > This way it's also a userspace choice and not an admin or whoever > > controls the cmdline (well, that's rather theoretical since the target > > is Android). > > I like the cmdline option more. It implies a custom bootloader and user space > are required to enable this. Which in return implies they can write their own > custom driver to manage exporting this info to user-space. Reliefing us from > maintaining any ABI in mainline kernel. Regardless of whether it's cmdline or sysctl, I'm strongly opposed to custom drivers for exposing this information to user. It leads to custom incompatible ABIs scattered around. Note that user can already check the MIDR_EL1 value if it knows which CPU type and revision has 32-bit support. -- Catalin
