This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] adjust non-default sized console ring allocation

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] adjust non-default sized console ring allocation
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 28 Aug 2009 09:14:11 +0100
Delivery-date: Fri, 28 Aug 2009 01:14:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Using xmalloc() for objects that are guaranteed to be at least as
large as a page is wasteful, as it will always result in more (here:
double the amount) being allocated.

The other adjustments are more cosmetic:
- Updating conring and conring_size can be done so NMI/MCE generated
  messages don't use the new (larger) size with the old (smaller)
- The size printed can be in KiB (for the value to be easier to grasp)
  since it is always a multiple of the default of 16KiB.

One remaining problem I see is that the allocation happens after all
CPUs got brought up: With that process (plus the prior ACPI table
parsing) being what generates (on large systems) by far the largest
amount of messages, one of the primary uses of that option - getting at
all boot messages - seems to be out of reach at present. Prior to
discovering this boot option exists at all (it didn't in 3.3) I was
about to implement a solution where the ring would sit at the end of
.bss, and thus be sizeable at very early boot time; maybe that's still
worth considering as an alternative to the current approach?

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

--- 2009-08-18.orig/xen/drivers/char/console.c  2009-08-24 17:51:39.000000000 
+++ 2009-08-18/xen/drivers/char/console.c       2009-08-26 16:47:56.000000000 
@@ -608,7 +608,7 @@ void __init console_init_postirq(void)
     if ( opt_conring_size < conring_size )
-    ring = xmalloc_bytes(opt_conring_size);
+    ring = alloc_xenheap_pages(get_order_from_bytes(opt_conring_size), 0);
     if ( ring == NULL )
         printk("Unable to allocate console ring of %u bytes.\n",
@@ -619,11 +619,12 @@ void __init console_init_postirq(void)
     for ( i = conringc ; i != conringp; i++ )
         ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
-    conring_size = opt_conring_size;
     conring = ring;
+    wmb();
+    conring_size = opt_conring_size;
-    printk("Allocated console ring of %u bytes.\n", opt_conring_size);
+    printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
 void __init console_endboot(void)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] adjust non-default sized console ring allocation, Jan Beulich <=