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

Re: [PATCH] xen/console: make console buffer size configurable


  • To: Denis Mukhin <dmkhn@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 25 Feb 2025 08:23:47 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: andrew.cooper3@xxxxxxxxxx, anthony.perard@xxxxxxxxxx, julien@xxxxxxx, michal.orzel@xxxxxxx, roger.pau@xxxxxxxxxx, sstabellini@xxxxxxxxxx, dmukhin@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 25 Feb 2025 07:23:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.02.2025 03:45, Denis Mukhin wrote:
> On Monday, February 24th, 2025 at 2:44 AM, Jan Beulich <jbeulich@xxxxxxxx> 
> wrote:
> 
>>
>>
>> On 21.02.2025 21:52, Denis Mukhin wrote:
>>
>>> On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich jbeulich@xxxxxxxx 
>>> wrote:
>>>
>>>> On 12.02.2025 23:31, dmkhn@xxxxxxxxx wrote:
>>>>
>>>>> --- a/xen/drivers/char/Kconfig
>>>>> +++ b/xen/drivers/char/Kconfig
>>>>> @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
>>>>>
>>>>> Default value is 32768 (32KiB).
>>>>>
>>>>> +config CONRING_SIZE
>>>>> + int "Console buffer size"
>>>>> + default 32768
>>>>> + range 16384 134217728
>>>>> + help
>>>>> + Select the boot console buffer size (in bytes).
>>>>
>>>> Why in bytes when ...
>>>>
>>>>> + Note, the value provided will be rounded down to the nearest power of 2.
>>>>
>>>> ... this rounding is done anyway? Why have people type in complicated 
>>>> numbers?
>>>> A granularity of 1k would already be an improvement; yet better would be if
>>>> this was a power-of-two value altogether.
>>>
>>> My understanding that the semantics of new CONFIG_CONRING_SIZE build-time 
>>> setting
>>> should be consistent with existing boot-time conring_size= behavior (string 
>>> value
>>> converted to number of bytes).
>>>
>>> I can update both to round up to 1k boundary.
>>>
>>> I also agree that having power of 2s for both (e.g. similar to Linux'es 
>>> CONFIG_LOG_BUF_SHIFT)
>>> will be the simplest (implementation) and non-ambigous.
>>> I had it done earlier:
>>> https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-26-e9aa923127eb@xxxxxxxx/
>>
>>
>> I'd prefer the power-of-2 approach, yet I could live with the Kb-based one as
>> was suggested by Roger.
> 
> Just to double check: I think it makes sense to switch both build-time and 
> run-time
> settings to use the same size calculation algorithm (e.g. Kb-based) to avoid
> confusion during building hypervisor configuration.
> 
> Will that be OK to do such change?

No, you can't change existing command line options like this, at least not
without a very good reason. You'd break existing uses. Plus there is

size_param("conring_size", opt_conring_size);

already anyway, so the command line option can be used with Kb and other
granularities without any adjustments to the code.

>>> Also, since there's a build-time configuration parameter along with the 
>>> boot-time
>>> configuration, perhaps it makes sense to retire boot-time setting in favor 
>>> of
>>> build-time setting?
>>
>>
>> Why would that be? Build-time settings can only ever be defaults. We don't
>> know what people need in their configurations.
> 
> I was thinking about few reasons.
> In embedded setup run-time settings are unlikely to change, it is mostly
> built-time configuration.
> On a server setup, bumping the size of console buffer morelikely means some
> debugging, which to me means new xen binary can be re-generated and 
> re-deployed.

That depends on who's doing the debugging and who's giving the instructions.
A developer telling a customer to increase the buffer size is certainly
easier when it simply means adding/changing a command line option, for
example.

Jan



 


Rackspace

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