Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Andi Kleen]

On Friday 16 February 2007 12:10, Keir Fraser wrote:
> 
> On 16/2/07 09:18, "Andi Kleen" <ak@muc.de> wrote:
> 
> >> It's for populating the pagetable in a vmalloc area.  There's magic in
> > 
> > If the lazy setup doesn't work for you you can always call vmalloc_sync()
> > early.
> 
> vmalloc_sync_all()? 

Yes.

Credit goes to Jan for writing it originally.

-Andi

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Hollis Blanchard]

On Fri, 2007-02-16 at 17:10 +0000, Keir Fraser wrote:
> 
> 
> On 16/2/07 16:46, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
> 
> > Yes, that would work.  Unfortunately that's i386 arch-specific, whereas
> > the rest of this code is generic.  I guess I could just move it all to
> > arch/i386/mm.
> 
> This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and
> powerpc doesn't use any of the Xen driver code at this time.

Not sure what you mean? PowerPC uses pretty much all of the Xen driver
code: event channels, blkfront/back, netfront/back, console, etc.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> On 16/2/07 17:10, "Keir Fraser" <keir@xensource.com> wrote:
>
>   
>> On 16/2/07 16:46, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
>>
>>     
>>> Yes, that would work.  Unfortunately that's i386 arch-specific, whereas
>>> the rest of this code is generic.  I guess I could just move it all to
>>> arch/i386/mm.
>>>       
>> This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and
>> powerpc doesn't use any of the Xen driver code at this time.
>> vmalloc_sync_all is supported by both i386 and x86_64, so we can make the
>> call conditional on CONFIG_X86 so that ia64 will continue to build. This is
>> what I've done in xen-unstable.
>>     
>
>
> In fact that file is only built for i386 and x86_64, so there really is no
> problem with using vmalloc_sync_all() directly and without ifdef.
>   

I had moved it to mm/vmalloc.c in response to previous review comments
(namely, its not Xen specific, so it shouldn't live in the Xen part of
the tree).

    J

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Keir Fraser]

On 16/2/07 19:06, "Keir Fraser" <keir@xensource.com> wrote:

>> I had moved it to mm/vmalloc.c in response to previous review comments
>> (namely, its not Xen specific, so it shouldn't live in the Xen part of
>> the tree).
> 
> Then the call will have to be CONFIG_X86. I hadn't realised powerpc were
> also using lock_vm_area. However I suspect that the x86 issue that those
> functions were written doesn't even exist on powerpc, or any other non-x86
> architecture.

Hmmm... Actually looks like a bunch of architectures do lazy sync of the
vmalloc area, although neither ia64 nor powerpc does so. However, all
current users of the alloc_vm_area() function would be okay since none of
the other lazy-syncing architectures are supported by Xen.

 -- Keir

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> Hmmm... Actually looks like a bunch of architectures do lazy sync of the
> vmalloc area, although neither ia64 nor powerpc does so. However, all
> current users of the alloc_vm_area() function would be okay since none of
> the other lazy-syncing architectures are supported by Xen.
>   

Well, assuming that alloc_vm_area() has some non-Xen use, the right
thing is for archs to export vmalloc_sync_all(), and just use that from
common code.

    J

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Keir Fraser]

On 16/2/07 19:26, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

> Keir Fraser wrote:
>> Hmmm... Actually looks like a bunch of architectures do lazy sync of the
>> vmalloc area, although neither ia64 nor powerpc does so. However, all
>> current users of the alloc_vm_area() function would be okay since none of
>> the other lazy-syncing architectures are supported by Xen.
>>   
> 
> Well, assuming that alloc_vm_area() has some non-Xen use, the right
> thing is for archs to export vmalloc_sync_all(), and just use that from
> common code.

It has no other users right now and get_vm_area_sync() would be a
better-named and more generically useful function than alloc_vm_area(). But
yes, to be done properly it does require vmalloc_sync_all() to be defined by
all architectures (even if that's BUG() and implement-properly-on-demand).

get_vm_area_sync(), partnered with existing remove_vm_area(), just seems
much smaller and neater than adding four new functions with a more complex
usage: alloc_vm_area, {lock,unlock}_vm_area, and free_vm_area. Maybe keeping
free_vm_area() too makes sense as its interface is more neatly symmetrical
to that of get_vm_area().

 -- Keir

Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> It has no other users right now and get_vm_area_sync() would be a
> better-named and more generically useful function than alloc_vm_area().
I'm thinking "reserve" might be a better term; "get" generally has the
suggestion of a refcount.

> get_vm_area_sync(), partnered with existing remove_vm_area(), just seems
> much smaller and neater than adding four new functions with a more complex
> usage: alloc_vm_area, {lock,unlock}_vm_area, and free_vm_area. Maybe keeping
> free_vm_area() too makes sense as its interface is more neatly symmetrical
> to that of get_vm_area().

I've already killed the lock/unlock functions.  I'll come up with
something for the get/allocate/reserve and free functions.

    J