Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig

[Juergen Gross <jgross@suse.com>]

On 18/12/15 11:45, Ian Campbell wrote:
> On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
>> Add machinery to allow the schedulers to be individually selectable
>> through the Kconfig interface.
> 
> So I don't want to pick on this series or schedulers specifically here, but
> instead discuss the general premise of configurability of hypervisor
> binaries, and this happens to be the first. I'm CCing Doug and "THE REST"
> from MAINTAINERS
> 
> Currently (even with the current switch to Kconfig thus far) we have a
> fairly small and manageable set of configurations which any given Xen
> binary can be in and in terms of what users are actually running an even
> smaller set I believe, most users fiddle with zero options and a small
> number with one or two. I'd hazard a guess that the vast majority of Xen
> binaries are using a single config today and that the second place is a
> fairly distant second.
> 
> This means we have avoided the combinatorial explosion of configuration
> options which Linux suffers from (which result in things like randconfig
> build robots because no one can keep track of it all).
> 
> Just to be clear: I'm not at all opposed to more configurability for expert
> users who have specific usecases, know what they are doing and are willing
> to take responsibility for developments deviating form the norm.
> 
> However I am very wary of putting shiny looking nobs in front of the
> average user, since they will find them and they will inevitably play with
> them and we will end up in the situation where every bug report involves an
> additional RTT while we ask for their .config (ok, in reality we'd often
> ask at the same time we inevitably have to ask for logs and other key info,
> so I guess I'm exaggerating, but still its a worry I think).
> 
> As well as support there is obviously a testing matrix impact.
> 
> How would people feel about a CONFIG_STANDARD_FEATURESET[0] with the
> majority of tweakables depending on !STANDARD_FEATURESET? It would default
> Y with a help text which dissuades normal users from touching it ("Say Y,
> unless you are willing to pick up the pieces yourself. We do not routinely
> test or validate configurations without this option set. We expect you to
> offer to fix issues which you find. Beware of the leopard.").[1]

What I'd really like to see in the config options are things like:

CONFIG_BIGMEM (instead of doing it via environment variable),
NR_CPUS, and possibly some other numerical bounds which won't select
a feature, but might be interesting to change for huge servers.


Juergen