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@citrix.com>
--
Changes since v2:
 - Bump to 128K.
---
 xen/drivers/char/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 06350c387371..1cd9cddfe1bf 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -77,13 +77,13 @@ config HAS_EHCI
 
 config SERIAL_TX_BUFSIZE
 	int "Size of the transmit serial buffer"
-	default 16384
+	default 131072
 	help
 	  Controls the default size of the transmit buffer (in bytes) used by
 	  the serial driver.  Note the value provided will be rounded down to
 	  the nearest power of 2.
 
-	  Default value is 16384 (16kiB).
+	  Default value is 131072 (128KiB).
 
 config XHCI
 	bool "XHCI DbC UART driver"
-- 
2.42.0

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@citrix.com>
> --
> 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 ...

Jan

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@citrix.com>
> > --
> > 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.

Thanks, Roger.

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@citrix.com>
>>> --
>>> 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.

Jan

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@citrix.com>
>>>> --
>>>> 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@xen.org/ 


> 
> Jan

-- 
Julien Grall

Hi Roger,

On 19/09/2023 13: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@citrix.com>

Acked-by: Julien Grall <jgrall@amazon.com>

I will commit it in a couple of days if there are no objection.

Cheers,

-- 
Julien Grall