On 18/01/2019 14:44, Andrew Cooper wrote: > On 18/01/2019 13:19, Juergen Gross wrote: >> On 18/01/2019 14:13, Andrew Cooper wrote: >>> On 10/12/2018 11:44, Juergen Gross wrote: >>>> With being able to specify a dom0_mem value depending on host memory >>>> size on x86 make it easy for distros to specify a default dom0 size by >>>> adding a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter >>>> value. >>>> >>>> It will be used only if no dom0_mem parameter was specified in the >>>> boot parameters. >>>> >>>> Signed-off-by: Juergen Gross <jgr...@suse.com> >>>> Reviewed-by: Jan Beulich <jbeul...@suse.com> >>> Why was this patch accepted? We've already got a suitable Kconfig >>> option for this, CONFIG_CMDLINE. >> Why do we have a config option for the default scheduler? > > That pre-dates CONFIG_CMDLINE, but is of dubious use.
I don't agree with you here. I think this is a very sensible choice. > >> >> And something like: >> >> dom0_mem=max:8G dom0_mem=10% >> >> is different from >> >> CONFIG_DOM0_MEM="max:8G" plus dom0_mem=10% >> >> on a host with say 100G of memory: In the first case this would be 8G, >> in the second case 10G. > > And? There is no way of preventing that. I wanted to say: using CONFIG_DOM0_MEM and CONFIG_CMDLINE are different. The former is evaluated only if the user doesn't specify dom0_mem as a parameter, while the latter _is_ cumulative. The advantage of CONFIG_DOM0_MEM is that is really only the default, not an additional setting the user has to take into acount. > A user can really put two dom0_mem= on the real command line, and could > put a dom0_mem in CONFIG_CMDLINE. Right, and then he'd have three cumulative settings. > The only solution to this problem is for the final dom0_mem= to be a > full specification, and I still see no use for CONFIG_DOM0_MEM So a user specifying dom0_mem in a 4.11 setup would eventually need to modify his setting. With CONFIG_DOM0_MEM he doesn't have to do that. Additionally CONFIG_CMDLINE is available in expert mode only, while CONFIG_DOM0_MEM can be set more easily. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
