| Message ID | 20230919125118.12657-1-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] console/serial: bump buffer from 16K to 128K | expand |
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,
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
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"
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(-)