Re: [PATCH v3] console/serial: bump buffer from 16K to 128K

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 19/09/2023 15:26, Jan Beulich wrote:
> On 19.09.2023 16:14, Roger Pau Monné wrote:
> > On Tue, Sep 19, 2023 at 03:06:45PM +0200, Jan Beulich wrote:
> > > On 19.09.2023 14:51, 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 128K 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 128K in order to cope with
> > > > current systems generating output faster does seem appropriate to have
> > > > a better user experience with the provided defaults.
> > > >
> > > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > > --
> > > > Changes since v2:
> > > >   - Bump to 128K.
> > > Wow, I was hesitant about 32k, and now we're going all the way up to 128?
> > > Even the recent report indicated 24k would be fine there ...
> > 24k would be rounded to 32k anyway.
> >
> > I don't think 32k vs 128k makes that much difference, it's still an
> > infinitesimal part of the memory on any modern computer.  Simply the
> > risk of loosing output is IMO not worth us being conservative with
> > the amount here, specially if we are speaking about KiB, not even MiB.
> Well, I've voiced my view on the underlying principle of this before. I
> don't mean to block the increase, but I wanted to express that when I
> was halfway okay with 32k, I find 128k excessive.
As discussed in [1], I have changed back the size fo 32K and committed 
patch.
Cheers,

[1] 
https://lore.kernel.org/xen-devel/55d92655-6fd8-430a-8b16-3f56693def9c@xxxxxxx/ 

> Jan
--
Julien Grall