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/