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
On 16/2/07 19:26, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> 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
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
On 16/2/07 19:06, "Keir Fraser" <[EMAIL PROTECTED]> 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
On 16/2/07 17:27, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
> 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
>
On Fri, 2007-02-16 at 17:10 +, Keir Fraser wrote:
>
>
> On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> 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
> >
Keir Fraser wrote:
> On 16/2/07 17:10, "Keir Fraser" <[EMAIL PROTECTED]> wrote:
>
>
>> On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Yes, that would work. Unfortunately that's i386 arch-specific, whereas
>>> the rest of this code is generic. I guess I could
On 16/2/07 17:10, "Keir Fraser" <[EMAIL PROTECTED]> wrote:
> On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> 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.
On 16/2/07 16:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> 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
On Friday 16 February 2007 12:10, Keir Fraser wrote:
>
> On 16/2/07 09:18, "Andi Kleen" <[EMAIL PROTECTED]> 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.
>
>
On 16/2/07 09:18, "Andi Kleen" <[EMAIL PROTECTED]> 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()? That's a great idea. We can put that in
On 16/2/07 09:18, Andi Kleen [EMAIL PROTECTED] 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()? That's a great idea. We can put that in alloc_vm_area()
and
On Friday 16 February 2007 12:10, Keir Fraser wrote:
On 16/2/07 09:18, Andi Kleen [EMAIL PROTECTED] 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()?
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] 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
On 16/2/07 17:10, Keir Fraser [EMAIL PROTECTED] wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] 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
On Fri, 2007-02-16 at 17:10 +, Keir Fraser wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] 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
Keir Fraser wrote:
On 16/2/07 17:10, Keir Fraser [EMAIL PROTECTED] wrote:
On 16/2/07 16:46, Jeremy Fitzhardinge [EMAIL PROTECTED] 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
On 16/2/07 17:27, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
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,
On 16/2/07 19:06, Keir Fraser [EMAIL PROTECTED] 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
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.
On 16/2/07 19:26, Jeremy Fitzhardinge [EMAIL PROTECTED] 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
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
22 matches
Mail list logo
