Re: [PATCH 2/2] console/serial: bump buffer from 16K to 32K

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.