On Wed, Jun 29, 2022 at 06:30:18PM +0200, Jan Beulich wrote: > On 29.06.2022 18:19, Roger Pau Monné wrote: > > On Wed, Jun 29, 2022 at 06:03:34PM +0200, Jan Beulich wrote: > >> On 29.06.2022 17:23, Roger Pau Monné wrote: > >>> On Thu, Jun 23, 2022 at 03:32:30PM +0200, Jan Beulich wrote: > >>>> On 23.06.2022 11:08, Roger Pau Monne wrote: > >>>>> Testing on a Kaby Lake box with 8 CPUs leads to the serial buffer > >>>>> being filled halfway during dom0 boot, and thus a non-trivial chunk of > >>>>> Linux boot messages are dropped. > >>>>> > >>>>> Increasing the buffer to 32K does fix the issue and Linux boot > >>>>> messages are no longer dropped. There's no justification either on > >>>>> why 16K was chosen, and hence bumping to 32K in order to cope with > >>>>> current systems generating output faster does seem appropriate to have > >>>>> a better user experience with the provided defaults. > >>>> > >>>> Just to record what was part of an earlier discussion: I'm not going > >>>> to nak such a change, but I think the justification is insufficient: > >>>> On this same basis someone else could come a few days later and bump > >>>> to 64k, then 128k, etc. > >>> > >>> Indeed, and that would be fine IMO. We should aim to provide defaults > >>> that work fine for most situations, and here I don't see what drawback > >>> it has to increase the default buffer size from 16kiB to 32kiB, and > >>> I would be fine with increasing to 128kiB if that's required for some > >>> use case, albeit I have a hard time seeing how we could fill that > >>> buffer. > >>> > >>> If I can ask, what kind of justification you would see fit for > >>> granting an increase to the default buffer size? > >> > >> Making plausible that for a majority of contemporary systems the buffer > >> is not large enough would be one aspect. But then there's imo always > >> going to be an issue: What if non-Linux Dom0 would be far more chatty? > >> What if Linux, down the road, was made less verbose (by default)? What > >> if people expect large enough a buffer to also suffice when Linux runs > >> in e.g. ignore_loglevel mode? We simply can't fit all use cases and at > >> the same time also not go overboard with the default size. That's why > >> there's a way to control this via command line option. > > > > Maybe I should clarify that the current buffer size is not enough on > > this system with the default Linux log level. I think we can expect > > someone that changes the default Linux log level to also consider > > changing the Xen buffer size. OTOH when using the default Linux log > > level the default Xen serial buffer should be enough. > > > > I haven't tested with FreeBSD on that system, other systems I have > > seem to be fine when booting FreeBSD with the default Xen serial > > buffer size. > > > > I think we should exercise caution if someone proposed to increase to > > 1M for example, but I don't see why so much controversy for going from > > 16K to 32K, it's IMO a reasonable value and has proven to prevent > > serial log loss when using the default Linux log level. > > But see - that's exactly my point. Where do you draw the line between > "we should accept" and "exercise caution"? Is it 256k? Or 512k?
Hard to tell, it would depend on the justification/use case for needed those buffer sizes. To be fair 16K seems equally random to me, I tried to backtrack to the commit it was introduced, but I haven't been able to find any justification. I think we can at least agree that making the buffer size configurable from Kconfig is a desirable move. Thanks, Roger.
