Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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, 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. I guess we should change the name of alloc_vm_area, by the way. Perhaps alloc_vm_area_sync() or similar, to give some hint of what it's doing and how it differs from other vmalloc-area functions? -- Keir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 >>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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. -- Keir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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. -- Keir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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()? Yes. Credit goes to Jan for writing it originally. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 kill {lock,unlock}_vm_area() which is a nice interface simplification.
Thanks!
Keir
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 kill {lock,unlock}_vm_area() which is a nice interface simplification.
Thanks!
Keir
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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()? Yes. Credit goes to Jan for writing it originally. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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. -- Keir - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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. -- Keir - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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, 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. I guess we should change the name of alloc_vm_area, by the way. Perhaps alloc_vm_area_sync() or similar, to give some hint of what it's doing and how it differs from other vmalloc-area functions? -- Keir - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
