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

Re: xl dmesg buffer too small for Xen 4.18?


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 19 Sep 2023 18:00:32 +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=GjCrAgWlyvI5Uvxzc0UklKUXmA77zIQqSDflY5FDbDo=; b=SXYMT14cEOYR1Y6bF3YJ0Ps0iWRZ8cGUgH3R4s87Y9ri+rO56YNiu9gP3LRvRFXVSo66SSllhMlqV7bFJKA2dk4SWdnYRInnQOaQqqAvEGRMgX5h6mCBLNwGwjCd9DcswzCfZQIW8/S8vDF2zipMMCb0pascKVL66RyNrAxJhHUZrgHgBOLuUqf6Vk8qmN2vJnZQvl/6PBto2dNvNterxqL+RMWJyxUKbn7IHVIlYZIk9351Qjp+85a1OUrMwckCRio6OU207J7Wn36lWnx6YcnNmex/rOpva121P/KW0mbtrixPk32muh+8uNOFRi24TYQxeHtT+ZmRQ2OXAW/nEw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MTAGPbKYryr/qXOrlKws9QpZa0rLR8tf6/33DWbXD+j9OeYo6170KFRnxV4prQ6ds5rf/CJUM2MnDlFk5Io8PydXesDMZs+MkFSLz8GDHHujFClremoxBSJjtUajkRVrdPam8bGFvGUJOAodGsq0dVsyVuW6moIPNXT5BGQt6902XxZKv2iQGflTqFbJm/jRlKNlb9d9vlYG451QvjbqQUbHwX45lp6W8iEyFPNOn30rfNNDjMCr2lH7zVcKkc3JsiHWnbKibbIJV2I+s0gRd9hDIaGMpr5M0YLmJcaupSvGpQjVPB0TiF9bIbnRR52hVg2b4Svcs1Oh2Scd6B+IdA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 19 Sep 2023 16:00:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.09.2023 17:56, Julien Grall wrote:
> On 19/09/2023 16:09, Chuck Zmudzinski wrote:
>> On 9/19/2023 8:10 AM, Julien Grall wrote:
>>> On 19/09/2023 08:02, Roger Pau Monné wrote:
>>>> On Mon, Sep 18, 2023 at 07:49:26PM +0100, Julien Grall wrote:
>>>>> (+Roger and moving to xen-devel)
>>>>> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
>>>>>> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>>>>>>> I tested Xen 4.18~rc0 on Alma Linux 9 and my first tests indicate it 
>>>>>>> works fine for starting the guests I manage but I notice that 
>>>>>>> immediately after boot and with only dom0 running on the system, I get:
>>>>>>>
>>>>>>> [user@Malmalinux ~]$ sudo xl dmesg
>>>>>>> 00bee72000-00000bee72fff type=7 attr=000000000000000f
>>>>>>> (XEN)  00000bee73000-00000bef49fff type=4 attr=000000000000000f
>>>>>>> (XEN)  00000bef4a000-00000bef4bfff type=7 attr=000000000000000f
>>>>>>> (XEN)  00000bef4c000-00000befbafff type=4 attr=000000000000000f
>>>>>>> (XEN)  00000befbb000-00000befbbfff type=7 attr=000000000000000f
>>>>>>> ...
>>>>>>>
>>>>>>> I have noticed the buffer fills up quickly on earlier Xen versions, but 
>>>>>>> never have I seen it fill up during boot and with only dom0 running.
>>>>>>>
>>>>>>> Can increasing the buffer fix this? How would one do that?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>> I see the setting is the command line option conring_size:
>>>>>>
>>>>>> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#conring_size
>>>>>>
>>>>>> The default is 16k, I tried 48k and that was big enough to capture all 
>>>>>> the messages at boot for 4.18 rc0. This is probably not an issue if the 
>>>>>> release candidate is being more verbose than the actual release will be. 
>>>>>> But if the release is still this verbose, maybe the default of 16k 
>>>>>> should be increased.
>>>>>
>>>>> Thanks for the report. This remind me the series [1] from Roger which 
>>>>> tries
>>>>> to increase the default size to 32K. @Roger, I am wondering if we should
>>>>> revive it?
>>>>
>>>> I think the relevant patch (2/2) will still apply as-is, it's just a
>>>> Kconfig one line change.  I'm however thinking it might be better to
>>>> bump it even further, to 128K.  From a system point of view it's still
>>>> a very small amount of memory.
>>>
>>> I don't have a strong opinion about 128K vs 32K.
>>
>> I am sure 32k will be big enough on my system, and based on Jan's comment
>> about release builds being less verbose, the current default of 16k may
>> still work on my system once the release is out. 
> 
> I think it is quite (actually more) important to capture all the logs 
> even in non-release build. So it would makes sense to increase the 
> buffer to 32KB.
> 
> An alternative option would be to have a different limit for debug and 
> production build. Not sure what the others thinks.

I would certainly like a two-way default better than the uniform bumping
to 128k.

Jan



 


Rackspace

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