All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, Jes Sorensen <jes@sgi.com>
Subject: Re: [Fwd: [patch] first boot allocator to not scan hole on every allocation]
Date: Thu, 14 Dec 2006 10:37:52 -0700	[thread overview]
Message-ID: <1166117872.5666.13.camel@lappy> (raw)
In-Reply-To: <457D7C01.1020703@sgi.com>

Hi Keir,

   Do you have any objections to this patch?  If not, I'd like to add it
to the xen-ia64-unstable.hg tree and let it get pulled into xen-unstable
after 3.0.4.  Let us know, thanks,

	Alex

On Mon, 2006-12-11 at 16:40 +0100, Jes Sorensen wrote:
> 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
> email message attachment ([patch] first boot allocator to not scan
> hole on every allocation)
> > -------- Forwarded Message --------
> > From: Jes Sorensen <jes@sgi.com>
> > To: xen-ia64-devel@lists.xensource.com
> > Cc: Alex Williamson <alex.williamson@hp.com>
> > Subject: [patch] first boot allocator to not scan hole on every
> > allocation
> > Date: Mon, 11 Dec 2006 16:01:35 +0100
> > 
> > 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
> > 
> > plain text document attachment (xen-boot-alloc-skip-hole.diff)
> > 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 )
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
-- 
Alex Williamson                             HP Open Source & Linux Org.

  reply	other threads:[~2006-12-14 17:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-11 15:40 [Fwd: [patch] first boot allocator to not scan hole on every allocation] Jes Sorensen
2006-12-14 17:37 ` Alex Williamson [this message]
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=1166117872.5666.13.camel@lappy \
    --to=alex.williamson@hp.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=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.