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 exi
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 oka
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 X
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
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
> > arch/i386/mm
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 lock_vm_area
Andi Kleen 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.
>
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic.
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.
>
> vmall
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(
> 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.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On Thu, 15 Feb 2007 23:30:57 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> > If you really need to run atomically, that gets ugly. Even of one were to
> > run handle_mm_fault() by hand, it still needs to allocate memory.
> >
> > Two ugly options might be:
> >
> > a) touch all the pages,
Andrew Morton wrote:
On Thu, 15 Feb 2007 23:08:02 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
Andrew Morton wrote:
This won't work when CONFIG_PREEMPT=y. The pagefault handler will see
in_atomic() and will scram.
Is there some other way to get the pagetable populated for the a
Andrew Morton wrote:
> On Thu, 15 Feb 2007 23:08:02 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> wrote:
>
>
>> Andrew Morton wrote:
>>
>>> This won't work when CONFIG_PREEMPT=y. The pagefault handler will see
>>> in_atomic() and will scram.
>>>
>>>
>> Is there some other way
On Thu, 15 Feb 2007 23:08:02 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> Andrew Morton wrote:
> > This won't work when CONFIG_PREEMPT=y. The pagefault handler will see
> > in_atomic() and will scram.
> >
>
> Is there some other way to get the pagetable populated for the address
>
Andrew Morton wrote:
> This won't work when CONFIG_PREEMPT=y. The pagefault handler will see
> in_atomic() and will scram.
>
Is there some other way to get the pagetable populated for the address
range?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Thu, 15 Feb 2007 18:25:01 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> +void lock_vm_area(struct vm_struct *area)
> +{
> + unsigned long i;
> + char c;
> +
> + /*
> + * Prevent context switch to a lazy mm that doesn't have this area
> + * mapped into its page ta
Allocate/destroy a 'vmalloc' VM area: alloc_vm_area and free_vm_area
The alloc function ensures that page tables are constructed for the
region of kernel virtual address space and mapped into init_mm.
Lock an area so that PTEs are accessible in the current address space:
lock_vm_area and unlock_vm
20 matches
Mail list logo
