> >> We also don't want multi-page allocations in this driver, so the
> >> batch size should be set accordingly.
> >
> > Why not?
>
> Multi-page allocations are more likely to fail because of memory
> fragmentation.
Since we're keeping the alignment restriction, the code stays pretty much the
sa
On 11/11/14 14:42, Thanos Makatos wrote:
>> On 11/11/14 12:27, Thanos Makatos wrote:
The arbitrary limitations in number of ops and page alignment should
be removed. I think both can be removed relatively easily by
consuming page aligned chunks of segments and doign the hypercall
>>
> On 11/11/14 12:27, Thanos Makatos wrote:
> >> The arbitrary limitations in number of ops and page alignment should
> >> be removed. I think both can be removed relatively easily by
> >> consuming page aligned chunks of segments and doign the hypercall
> >> when a batch of ops is filled.
> >
> >
On 11/11/14 12:27, Thanos Makatos wrote:
>> The arbitrary limitations in number of ops and page alignment should be
>> removed. I think both can be removed relatively easily by consuming page
>> aligned chunks of segments and doign the hypercall when a batch of ops is
>> filled.
>
> Wouldn't this
> The arbitrary limitations in number of ops and page alignment should be
> removed. I think both can be removed relatively easily by consuming page
> aligned chunks of segments and doign the hypercall when a batch of ops is
> filled.
Wouldn't this lead to multiple calls to gnttab_batch_copy(), p
