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
