Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus [and 1 more messages]

[Jürgen Groß <jgross@xxxxxxxx>]

On 06.04.20 13:11, Jan Beulich wrote:
> On 06.04.2020 13:00, Ian Jackson wrote:
> > Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels 
> > dependant on vcpus"):
> > > There are no correlation between event channels and vCPUs. The number of
> > > event channels only depends on the number of frontend you have in your
> > > guest. So...
> > >
> > > Hi Ian,
> > >
> > > On 06/04/2020 11:47, Ian Jackson wrote:
> > > > If ARM folks want to have a different formula for the default then
> > > > that is of course fine but I wonder whether this might do ARMk more
> > > > harm than good in this case.
> > > ... 1023 event channels is going to be plenty enough for most of the use
> > > cases.
> > OK, thanks for the quick reply.
> >
> > So, Jürgen, I think everyone will be happy with this:
> I don't think I will be - my prior comment still holds on there not
> being any grounds to use a specific OS kernel's (and to be precise
> a specific OS kernel version's) requirements for determining
> defaults. If there was to be such a dependency, then OS kernel
> [variant] should be part of the inputs to such a (set of) formula(s).
IMO this kind of trying to be perfect will completely block a sane
heuristic for being able to boot large guests at all.

The patch isn't about to find an as stringent as possible upper
boundary for huge guests, but a sane value being able to boot most of
those.

And how should Xen know the OS kernel needs exactly after all?

And it is not that we talking about megabytes of additional memory. A
guest with 256 vcpus will just be able to use additional 36 memory
pages. The maximum non-PV domain (the probably only relevant case
of another OS than Linux being used) with 128 vcpus would "waste"
32 kB. In case the guest misbehaves.

The alternative would be to do nothing and having to let the user
experience a somewhat cryptic guest crash. He could google for a
possible solution which would probably end in a rather high static
limit resulting in wasting even more memory.


Juergen