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

Re: [Xen-devel] [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb

>>> On 30.03.16 at 18:44, <konrad.wilk@xxxxxxxxxx> wrote:
> On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote:
>> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
>> >      return p;
>> >  }
>> >  
>> > -void vfree(void *va)
>> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
>> Just to repeat: This "caller provides size" worries me, the more that
>> this doesn't mirror anything the allocation side does. Would you mind
>> providing a case where using vm_size() instead is not correct?
> When the virtual addresses (to which we will stitch the pages allocated
> by vmalloc) are not allocated (provided?) by vmap.
> vm_size() will be very unhappy if that virtual address it is provided with
> are not from the 'vmap' pool and will return 0.

Hmm, okay, I now see that I got mislead by "This allows users (such
as xSplice) to provide their own mechanism to set the page flags",
which suggested to me that all you want is control over those flags.
Now that I look again I realize that I could have easily spotted the
actual intention right away. If all you really want to re-use from the
existing vmalloc() is the allocation mechanism of the set of pages,
then no, I don't think this should be done by playing with vmalloc().
Just have your caller do that allocation itself.

If, otoh, you left that VA management to (an extended version of)
vmap(), by e.g. allowing the caller to request allocation from a
different VA range (much like iirc x86-64 Linux handles its modules
address range allocation), things would be different. After all the
VA management is the important part here, while the backing
memory allocation is just a trivial auxiliary operation.


Xen-devel mailing list



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