From: Jes Sorensen <jes@sgi.com>
To: xen-devel@lists.xensource.com
Subject: [Fwd: [patch] first boot allocator to not scan hole on every allocation]
Date: Mon, 11 Dec 2006 16:40:49 +0100 [thread overview]
Message-ID: <457D7C01.1020703@sgi.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 236 bytes --]
Hi,
Alex suggested I send this one straight to xen-devel given it's
generic code.
I would claim it's harmless to architectures which have memory
starting 0x00 and it's absolutely vital for those architectures that
don't.
Cheers,
Jes
[-- Attachment #2: [patch] first boot allocator to not scan hole on every allocation --]
[-- Type: message/rfc822, Size: 3436 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 394 bytes --]
Hi,
Ok, I finally figured out why the boot allocator took .0172 seconds
for each single page allocation on a small Altix (a partitioned system
would be even worse). I posted a patch for this earlier, but it was
wrong (by a factor of 0x40 :-( ).
This patch goes into common/page_alloc.c but it should be obviously
correct.
It's really vital for the SN2 port to get this one in.
Cheers,
Jes
[-- Attachment #2.1.2: xen-boot-alloc-skip-hole.diff --]
[-- Type: text/plain, Size: 2186 bytes --]
Keep track of which page is the first available to the boot allocator
to avoid scanning the hole "0 ... first_pg" on every allocation, on
platforms that do not have physical memory starting at address 0x00.
This reduces the Xen boot time by roughly 150 seconds on a small
Altix with 6GB of RAM.
Signed-off-by: Jes Sorensen <jes@sgi.com>
diff -r 66609699c9d0 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Fri Dec 08 14:29:42 2006 +0100
+++ b/xen/common/page_alloc.c Mon Dec 11 15:54:10 2006 +0100
@@ -137,6 +137,8 @@ static void map_alloc(unsigned long firs
}
+static unsigned long first_pg = -1UL;
+
static void map_free(unsigned long first_page, unsigned long nr_pages)
{
unsigned long start_off, end_off, curr_idx, end_idx;
@@ -152,6 +154,13 @@ static void map_free(unsigned long first
start_off = first_page & (PAGES_PER_MAPWORD-1);
end_idx = (first_page + nr_pages) / PAGES_PER_MAPWORD;
end_off = (first_page + nr_pages) & (PAGES_PER_MAPWORD-1);
+
+ /*
+ * Set first_pg to the first entry initialized so the boot
+ * allocator can avoid scanning the hole from 0 for no reason
+ */
+ if (first_page < first_pg)
+ first_pg = first_page;
if ( curr_idx == end_idx )
{
@@ -258,7 +267,7 @@ unsigned long alloc_boot_pages(unsigned
{
unsigned long pg, i = 0;
- for ( pg = 0; (pg + nr_pfns) < max_page; pg += pfn_align )
+ for ( pg = first_pg; (pg + nr_pfns) < max_page; pg += pfn_align )
{
i = alloc_boot_pages_at(nr_pfns, pg);
if (i != 0)
@@ -301,7 +310,7 @@ void end_boot_allocator(void)
INIT_LIST_HEAD(&heap[i][j][k]);
/* Pages that are free now go to the domain sub-allocator. */
- for ( i = 0; i < max_page; i++ )
+ for ( i = first_pg; i < max_page; i++ )
{
curr_free = next_free;
next_free = !allocated_in_map(i+1);
@@ -482,7 +491,7 @@ void scrub_heap_pages(void)
printk("Scrubbing Free RAM: ");
- for ( pfn = 0; pfn < max_page; pfn++ )
+ for ( pfn = first_pg; pfn < max_page; pfn++ )
{
/* Every 100MB, print a progress dot. */
if ( (pfn % ((100*1024*1024)/PAGE_SIZE)) == 0 )
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next reply other threads:[~2006-12-11 15:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-11 15:40 Jes Sorensen [this message]
2006-12-14 17:37 ` [Fwd: [patch] first boot allocator to not scan hole on every allocation] Alex Williamson
2006-12-14 18:11 ` Keir Fraser
2006-12-14 18:33 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=457D7C01.1020703@sgi.com \
--to=jes@sgi.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.