Re: [Xen-devel] [RFC PATCH v2] xen: free_domheap_pages: delay page scrub to idle loop

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.05.14 at 10:47, <bob.liu@xxxxxxxxxx> wrote:
> On 05/20/2014 04:20 PM, Jan Beulich wrote:
>> - explain why alternative approaches (like the suggested flagging of the
>>   pages as needing scrubbing during freeing, and doing the scrubbing in
> 
> Could you expand a bit more on how to use the idle cpus to do the
> scrubbing in background without impact other guests?

The only thing that needs specific consideration is the desire to
not have everyone contend on a global lock. Beyond that it
ought to be mostly mechanical: You'd need a quick way for CPUs
to find pages that need scrubbing (e.g. by adding a second link
field to struct page_info, even if this may need careful field
re-organization), and you need to deal with the race between
idle and allocation based scrubbing.

Ideally we would also take NUMA information into account here,
i.e. prefer scrubbing pages on CPUs close to the memory.

>>   the background as well as on the allocation path) are worse, or at least
> 
> Do you mean we can delay the page scrubbing to alloc_heap_pages()?
> 
> free_domheap_pages()
> {
>     if ( unlikely(d->is_dying) )
>     {
>         //set page flag to need scrubbing, and then free
>         free_heap_pages(pg);
>     }
> }
> 
> alloc_heap_pages()
> {
>     for ( ; ; )
>     {
>         if ( (pg = page_list_remove_head(&heap(node, zone, j))) )
>             goto found;
>     }
> 
> found:
>     if (page tagged with need scrubbing)
>         scrub_one_page(pg);
> }

Yes, along those lines, but of course with taking order > 0 into account.
That may involve deferring the merging of chunks until after scrubbing
was done, or having an efficient way to know from a higher order chunk
which lower order parts of it still need to be scrubbed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel