WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] tools: fix build after recent xenpaging changes

On Fri, 2011-06-24 at 15:35 +0100, Olaf Hering wrote:
> On Fri, Jun 24, Ian Campbell wrote:
> 
> > > The break exits the for() loop, not the while(1). In the next iteration
> > > page 1 may still be in paging->bitmap and tried again.
> > 
> > I'd missed the interrupted -> 1 in the while loop. I presume there is
> > some other exit condition which triggers once everything has been paged
> > back in and actually causes the daemon to exit?
> 
> If the for() loop found nothing, then this triggers:
> 
> 775             /* If no more pages to process, exit loop */
> 776             if ( i == paging->domain_info->max_pages )
> 777                 break;

Oh yes.

It's a bit counter intuitive to have a for loop which only processes the
first thing it finds and then relying on going round another outer loop
to pickup the second etc. It's at least O(N^2), isn't it?

Why not 
        count = 0;
        for ( i = 0; i < paging->domain_info->max_pages; i++ )
            {
                if ( test_bit(i, paging->bitmap) )
                {
                    page_in_trigger(i);
                    count++
                }
            }
            /* If no more pages to process, exit loop */
            if ( !count )
                break;

That will at least process as many pages as it can on each iteration
through the outer loop. Although it will most likely exacerbate the
locking issue I pointed to earlier.

Ian.


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