[PATCH] xen: increase static dmesg buffer to 64K

[PATCH] xen: increase static dmesg buffer to 64K

[Olaf Hering]

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# 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.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 31dd84463eec -r c6cade90d47f xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -53,7 +53,7 @@ boolean_param("console_timestamps", opt_
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE (64 * 1024)
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;

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

[Jan Beulich]

>>> On 17.07.11 at 17:43, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # 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.

Additionally I think we greatly reduced the amount of per-CPU
messages printed by default. So one other thing to do would be to
look into completely suppressing all per-CPU messages by default if
these are still causing trouble.

Jan

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 31dd84463eec -r c6cade90d47f xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -53,7 +53,7 @@ boolean_param("console_timestamps", opt_
>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> +#define _CONRING_SIZE (64 * 1024)
>  #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
>  static char __initdata _conring[_CONRING_SIZE];
>  static char *__read_mostly conring = _conring;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 

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

[Olaf Hering]

On Mon, Jul 18, Jan Beulich wrote:

> >>> On 17.07.11 at 17:43, Olaf Hering <olaf@aepfle.de> wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # 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?

Olaf

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

[Jan Beulich]

>>> On 18.07.11 at 10:16, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jul 18, Jan Beulich wrote:
> 
>> >>> On 17.07.11 at 17:43, Olaf Hering <olaf@aepfle.de> wrote:
>> > # HG changeset patch
>> > # User Olaf Hering <olaf@aepfle.de>
>> > # 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

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

[Keir Fraser]

On 18/07/2011 09:16, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Mon, Jul 18, Jan Beulich wrote:
> 
>>>>> On 17.07.11 at 17:43, Olaf Hering <olaf@aepfle.de> wrote:
>>> # HG changeset patch
>>> # User Olaf Hering <olaf@aepfle.de>
>>> # 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?

Are you actually losing messages because you can't allocate the larger
console ring early enough? It seems a bit unlikely, but possible I suppose.
Anyhow, the normal memory allocator is available plenty early enough. You'd
just need to do the allocation earlier than console_init_postirq(). Sometime
soon after the call to end_boot_allocator() would work nicely.

 -- Keir

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

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

[Olaf Hering]

On Mon, Jul 18, Keir Fraser wrote:

> On 18/07/2011 09:16, "Olaf Hering" <olaf@aepfle.de> wrote:
> > 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?
> 
> Are you actually losing messages because you can't allocate the larger
> console ring early enough? It seems a bit unlikely, but possible I suppose.

Yes, I was booting with conring_size=, but the bulk of messages were
already printed at that point. My 80 cpu testbox had 24K in dmesg buffer
with my patch.

> Anyhow, the normal memory allocator is available plenty early enough. You'd
> just need to do the allocation earlier than console_init_postirq(). Sometime
> soon after the call to end_boot_allocator() would work nicely.

I will put that on my TODO list, and look at your and Jans suggestion to
move the dmesg buffer allocation earlier.

Olaf