[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Fwd: [patch] first boot allocator to not scan hole on every allocation]



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@xxxxxxx>
> > To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > Cc: Alex Williamson <alex.williamson@xxxxxx>
> > 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@xxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
-- 
Alex Williamson                             HP Open Source & Linux Org.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.