[RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs

Will Deacon will at kernel.org
Wed Oct 21 13:23:46 EDT 2020


On Wed, Oct 21, 2020 at 05:07:30PM +0100, Qais Yousef wrote:
> On 10/21/20 16:23, Will Deacon wrote:
> > > > If a cpumask is easier to implement and easier to use, then I think that's
> > > > what we should do. It's also then dead easy to disable if necessary by
> > > > just returning 0. The only alternative I would prefer is not having to
> > > > expose this information altogether, but I'm not sure that figuring this
> > > > out from MIDR/REVIDR alone is reliable.
> > > 
> > > I did suggest this before, but I'll try gain. If we want to assume a custom
> > > bootloader and custom user space, we can make them provide the mask.
> > 
> > Who mentioned a custom bootloader? In the context of Android, we're
> 
> Custom bootloader as in a bootloader that needs to opt-in to enable the
> feature (pass the right cmdline param). Catalin suggested to make this a sysctl
> to allow also for runtime toggling. But the initial intention was to have this
> to enable it at cmdline.

Hmm, ok, I don't think allowing the cmdline to be specified means its a
custom bootloader.

> > talking about a user-space that already manages scheduling affinity.
> > 
> > > For example, the new sysctl_enable_asym_32bit could be a cpumask instead of
> > > a bool as it currently is. Or we can make it a cmdline parameter too.
> > > In both cases some admin (bootloader or init process) has to ensure to fill it
> > > correctly for the target platform. The bootloader should be able to read the
> > > registers to figure out the mask. So more weight to make it a cmdline param.
> > 
> > I think this is adding complexity for the sake of it. I'm much more in
> 
> I actually think it reduces complexity. No special ABI to generate the mask
> from the kernel. The same opt-in flag is the cpumask too.

Maybe I'm misunderstanding your proposal but having a cpumask instead of
a bool means you now have to consider policy on a per-cpu basis, which
adds an extra dimension to this. For example, do you allow that mask to
be changed at runtime so that differents sets of CPUs now support 32-bit?
Do you preserve it across hotplug?

Will



More information about the linux-arm-kernel mailing list