Re: [Xen-devel] [PATCH] xen: increase static dmesg buffer to 64K

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 18.07.11 at 10:16, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Mon, Jul 18, Jan Beulich wrote:
> 
>> >>> On 17.07.11 at 17:43, Olaf Hering <olaf@xxxxxxxxx> wrote:
>> > # HG changeset patch
>> > # User Olaf Hering <olaf@xxxxxxxxx>
>> > # Date 1310917380 -7200
>> > # Node ID c6cade90d47f32e19f529930ba9f9acfa69f065f
>> > # Parent  31dd84463eece20bd01c7aee22b52a0c06c67545
>> > xen: increase static dmesg buffer to 64K
>> > 
>> > On large systems the static dmesg buffer will overflow the 16K buffer, 
> early
>> > messages are lost. Increase the size to 64K to capture all lines on systems
>> > without serial console.
>> 
>> Please don't - on small systems it's a waste, and on even larger
>> systems it still won't help. If anything, the dynamic allocation may
>> need to happen earlier. As you probably saw, console_init_postirq()
>> already sizes the buffer dependent on the number of CPUs in the
>> system.
> 
> I think conring_size= should be evaluated very early. Is there a way to
> allocate a range of mfns very early which can then be used for the dmesg
> buffer?

Allocation can happen after the second phase of memory setup (the
loop following the comment starting with "Walk every RAM region and
map it in its entirety" in xen/arch/x86/setup.c). With some caution
(and awareness of perhaps pointlessly using memory below 4G) it
should even be doable after the first phase of memory initialization
(the preceding loop) or at the point where acpi_boot_table_init()
gets called (because that I expect to be where the bulk of the
messages comes from).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel