[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime
Hi Julien, On 23.05.2022 22:00, Julien Grall wrote: > > > On 23/05/2022 11:21, Michal Orzel wrote: >> Hi Julien, > > Hi Michal, > >> >> On 23.05.2022 12:05, Julien Grall wrote: >>> Hi, >>> >>> On 23/05/2022 10:13, Michal Orzel wrote: >>>> Introduce a command line parameter "maxcpus" on Arm to allow adjusting >>>> the number of CPUs to activate. >>> >>> The current definition "maxcpus" is not really suitable for big.LITTLE >>> systems as you have no flexibility to say how many types of each cores you >>> want to boot. >>> >>> Instead, Xen will pick-up the first CPUs it parsed from the firmware tables. >>> >>> >>> So what's your use-case/target? >>> >> - use cases where we have no big little (although even on big.LITTLE >> limiting this number makes sense if we do not care about the types) > > This may make sense in debug build, but for prod I think you need some > certainty how which CPUs you are going to use. My conviction was that using big.LITTLE by enabling hmp-unsafe is not really used in the production systems (after all it's called *unsafe*) as it may easily end up in an insecure/unstable platform without specifying the cpu affinity (which must be done carefully). > > So I would like a warning in the documentation "maxcpus" that in big.LITTLE > system, there are no guarantee on which types will be used. I'm fully ok with adding this warning. **WARNING: On Arm big.LITTLE systems, when `hmp-unsafe` option is enabled, this command line option does not guarantee on which CPU types will be used.** > > This is technically a lie, but I don't want a user to start relying on how > Xen will parse the DT. > >> - debug cases where we want to set maxcpus=1 > > Thanks for the clarification. I would be happy to add my tag with a warning > in the documentation. > Does it mean you want to do this on commit or should I handle it in v2? > Cheers, > Cheers, Michal
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |