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

Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use



On 23/01/15 16:00, David Vrabel wrote:
> On 23/01/15 15:47, Roger Pau Monné wrote:
>> El 23/01/15 a les 15.54, David Vrabel ha escrit:
>>> On 23/01/15 14:31, Roger Pau Monné wrote:
>>>> El 19/01/15 a les 16.51, David Vrabel ha escrit:
>>>>> +         if (invcount) {
>>>>> +                 ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, 
>>>>> invcount);
>>>>>                   BUG_ON(ret);
>>>>> -                 put_free_pages(blkif, unmap_pages, invcount);
>>>>> -                 invcount = 0;
>>>>> +                 xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
>>>>>           }
>>>>> - }
>>>>> - if (invcount) {
>>>>> -         ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
>>>>> -         BUG_ON(ret);
>>>>> -         put_free_pages(blkif, unmap_pages, invcount);
>>>>> +         pages += batch;
>>>>> +         num -= batch;
>>
>> This should be fixed to at least be (which is still not fully correct,
>> but it's better):
>>
>> pages += invcount;
>> num -= invcount;
>>
>> I hope an example will clarify this, suppose we have the following pages
>> array:
>>
>> pages[0] = persistent grant
>> pages[1] = persistent grant
>> pages[2] = regular grant
>> pages[3] = persistent grant
>> pages[4] = regular grant
>>
>> And batch is 1. In this case, the unmapped grant will be pages[2], but
>> then due to the code below pages will be updated to point to &pages[1],
>> which has already been scanned. If this was done correctly pages should
>> point to &pages[3]. As said, it's not really a bug, but the loop is
>> sub-optimal.
> 
> Ah ha.  Thanks for the clear explanation.
> 
> gnttab_blkback_unmap_prepare() stops once its been through the whole
> batch regardless of whether it filled the array with ops so we don't
> check a page twice but this does mean we have a sub-optimal number of ops.

This is not a hot path (it's only called during error recovery).  Are
you happy to leave this as is?

David

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


 


Rackspace

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