Re: xl dmesg buffer too small for Xen 4.18?

Re: xl dmesg buffer too small for Xen 4.18?

[Julien Grall]

(+Roger and moving to xen-devel)

Hi,

On 18/09/2023 19:17, Chuck Zmudzinski wrote:
> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>> Hello,
>>
>> 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?

Cheers,

[1] 
https://lore.kernel.org/xen-devel/20220630082330.82706-1-roger.pau@citrix.com/

-- 
Julien Grall

Re: xl dmesg buffer too small for Xen 4.18?

[Chuck Zmudzinski]

On 9/18/2023 2:49 PM, Julien Grall wrote:
> (+Roger and moving to xen-devel)
> 
> Hi,
> 
> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
>> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>>> Hello,
>>>
>>> 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?
> 
> Cheers,
> 
> [1] 
> https://lore.kernel.org/xen-devel/20220630082330.82706-1-roger.pau@citrix.com/
> 

I just tested with 24k, and that is also big enough. So 32k would also be good. But the default of 16k appears to be too small for Xen 4.18 rc0 on my machine.

Re: xl dmesg buffer too small for Xen 4.18?

[Jan Beulich]

On 18.09.2023 20:49, Julien Grall wrote:
> 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.

Just to mention it: Log-level defaults are different for debug and release builds,
which means release builds are typically less verbose.

Jan

Re: xl dmesg buffer too small for Xen 4.18?

[Roger Pau Monné]

On Mon, Sep 18, 2023 at 07:49:26PM +0100, Julien Grall wrote:
> (+Roger and moving to xen-devel)
> 
> Hi,
> 
> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
> > On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
> > > Hello,
> > > 
> > > 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'm happy to repost with an increased buffer size, but only if there's
someone willing to Ack it, otherwise it's not worth spending time on
it.

Thanks, Roger.

Re: xl dmesg buffer too small for Xen 4.18?

[Julien Grall]

Hi Roger,

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)
>>
>> Hi,
>>
>> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
>>> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>>>> Hello,
>>>>
>>>> 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'm happy to repost with an increased buffer size, but only if there's
> someone willing to Ack it, otherwise it's not worth spending time on
> it.

Sorry that patch fell through the cracks. I would be happy to ack the patch.

Cheers,

-- 
Julien Grall

Re: xl dmesg buffer too small for Xen 4.18?

[Chuck Zmudzinski]

On 9/19/2023 8:10 AM, Julien Grall wrote:
> Hi Roger,
> 
> 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)
>>>
>>> Hi,
>>>
>>> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
>>>> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>>>>> Hello,
>>>>>
>>>>> 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 am willing to defer to
whatever the developers decide according to the ordinary process for deciding
such questions.

> 
>> 
>> I'm happy to repost with an increased buffer size, but only if there's
>> someone willing to Ack it, otherwise it's not worth spending time on
>> it.
> 
> Sorry that patch fell through the cracks. I would be happy to ack the patch.
> 
> Cheers,
> 

Re: xl dmesg buffer too small for Xen 4.18?

[Julien Grall]

Hi Chuck,

On 19/09/2023 16:09, Chuck Zmudzinski wrote:
> On 9/19/2023 8:10 AM, Julien Grall wrote:
>> Hi Roger,
>>
>> 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)
>>>>
>>>> Hi,
>>>>
>>>> On 18/09/2023 19:17, Chuck Zmudzinski wrote:
>>>>> On 9/18/2023 9:00 AM, Chuck Zmudzinski wrote:
>>>>>> Hello,
>>>>>>
>>>>>> 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.

Cheers,

-- 
Julien Grall

Re: xl dmesg buffer too small for Xen 4.18?

[Jan Beulich]

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

Re: xl dmesg buffer too small for Xen 4.18?

[Chuck Zmudzinski]

On 9/19/2023 12:00 PM, Jan Beulich wrote:
> 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

I think for release builds (production) minimize it as much as possible without
losing the less verbose logs. For debug builds, make it as big as needed for
the convenience of developers and the more verbose logs.

Re: xl dmesg buffer too small for Xen 4.18?

[Roger Pau Monné]

On Tue, Sep 19, 2023 at 06:00:32PM +0200, Jan Beulich wrote:
> 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.

It's not just the output from Xen that goes into such buffer, but also
the output from dom0.  Hence making the decision based on Xen release
vs debug builds doesn't seem reliable to me.

Again 128K is a trivial amount of memory on current systems, I'm quite
sure 32K is already not enough on some of the systems I test with, but
anyway.  Feel free to pick and adjust the patch to 32K if that's the
only option, in any case it's better than the current default of 16K.

Thanks, Roger.

Re: xl dmesg buffer too small for Xen 4.18?

[Julien Grall]

Hi Roger,

On 19/09/2023 17:10, Roger Pau Monné wrote:
> On Tue, Sep 19, 2023 at 06:00:32PM +0200, Jan Beulich wrote:
>> 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.
> 
> It's not just the output from Xen that goes into such buffer, but also
> the output from dom0.  Hence making the decision based on Xen release
> vs debug builds doesn't seem reliable to me.

Fair point. It seems to me you want to have a size that cover pretty 
much everyone. Which is fine, but may have unintented impact on user 
that want to reduce the footprint of Xen.

> 
> Again 128K is a trivial amount of memory on current systems

I am not sure I would call it trivial. For Arm, this is about 12% of the 
size of Xen (currently about 1MB). Right now, I am not aware of users 
that may try to have a very slim down Xen. But I wouldn't suprised if 
this will come up in the future and therefore reserving 128K for the 
console may not be desirable.

Admittly those users would likely try to tailor Xen. So a bigger default 
would not matter. But this is showing that there are conflicting 
requirements and we need to find a middle ground.

> , I'm quite
> sure 32K is already not enough on some of the systems I test with, but
> anyway.  Feel free to pick and adjust the patch to 32K if that's the
> only option, in any case it's better than the current default of 16K.

Jan seems to be more happy with 32K. So I will adjust the patch to 32K. 
We can refine it if we notice that this is not sufficient for most of 
the systems.

Cheers,

---
Julien Grall