[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 29 Jun 2022 18:03:34 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s4IMaJrfXu0opUtaqtqlrlFOx+Xz3+lkJ6UvFcjDn7o=; b=ai/iVJHLlzeUG4a5RK6vVNpJ/bgr6bzwHjVLh6VXUB3bCdXPOj+XwdpkhT2picMcuCUnTCWCkzb3t/scM8yi8ot9scT+mzA9EmlsU6QfCRhy5DI/d/23ZX0mfJR8+Jk4OoeSgLqkpUIh54EtjZnPrbKzsixpnuF+cPZit6JMaKI2Sk3LjXGFDYMIRuJmFmYuCEbyvT069mYWSISPzOHfpzMmo+87pgL0fGTfMXy26E42zjNtltOspBUMiwjzYKtm8b+/+xaEgaZtsm+PWgR2X32DsrDid/P1GII9XGl8hLyKyECG/M1qEGH7c3DeJDdmbKoddL+0ysdtm90zmuuhug==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=apZCgQuSeNYul390UfHJOxIyFMYuSlRgMhpZCBLelB5tpSHd+qTaz326BWZBbNmQV8IoDJF3vZIeXa0g7UxGbKsCanpGVwHVjVJkjIgnguxSTmfD6dipndlK0etu9CgZv75IgBEDfOPAtDcOAa6zVlUcV+7DwkZCitsXxVNwVL7qkQO+wgzUZ8CfeoRle8V4WVbqlv0w9WME9BI0AWAT+/1UFNrmYbpwYDF5WwvN6pX64fjHJCE6agTckwkR2MMkM/WkPNMKxvFSbVFZsrdrej47Ik2KzPpuAQvbwAsIzwXLT7kWVdOyTB1SwMrNSbKYc3BPHiv8uBOFHMAoUqZ/gg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 29 Jun 2022 16:03:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.