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.
