From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 0/4] Allow schedulers to be selectable through Kconfig Date: Fri, 18 Dec 2015 12:08:12 +0100 Message-ID: <5673E91C.2090102@suse.com> References: <1450385974-12732-1-git-send-email-jonathan.creekmore@gmail.com> <1450435531.4053.196.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9stW-0007Ki-QW for xen-devel@lists.xenproject.org; Fri, 18 Dec 2015 11:08:18 +0000 In-Reply-To: <1450435531.4053.196.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Jonathan Creekmore , xen-devel@lists.xenproject.org Cc: Keir Fraser , Ian Jackson , Jan Beulich , Doug Goldstein , Tim Deegan List-Id: xen-devel@lists.xenproject.org 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