Prev: (none)
Next: [PATCH] lib/scatterlist: Hook sg_kmalloc into kmemleak (v2)
From: Nick Piggin on 27 Jul 2010 04:30
On Mon, Jul 26, 2010 at 01:24:51PM -0700, Jeremy Fitzhardinge wrote:
>
>
> [ Nick, I forget if I sent this to you before. Could you Ack it if it looks OK? Thanks, J ]
>
> Add a flag to force lazy_max_pages() to zero to prevent any outstanding
> mapped pages. We'll need this for Xen.

You have sent this to me before, probably several times, and I always
forget about it right as you send it again.

It's no problem merging something like this for Xen, although as you
know I would love to see an approach where Xen would benefit from
delayed flushing as well :)

You will need to disable lazy flushing from the per-cpu allocator
(vm_map_ram/vm_unmap_ram, which are used by XFS now). That's not
tied to the lazy_max stuff (which it should be, arguably)

That code basically allocates per-cpu chunks of va from the global
allocator, uses them, then frees them back to the global allocator
all without doing any TLB flushing.

If you have to do global TLB flushing there, then it's probably not
much value in per-cpu locking of the address allocator anyway, so
you could just add a test for vmap_lazy_unmap in these branches:

if (likely(count <= VMAP_MAX_ALLOC) && !vmap_lazy_unmap)

Thanks,
Nick

>
> Signed-off-by: Jeremy Fitzhardinge<jeremy.fitzhardinge(a)citrix.com>
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 227c2a5..b840fda 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -7,6 +7,8 @@
>
> struct vm_area_struct; /* vma defining user mapping in mm_types.h */
>
> +extern bool vmap_lazy_unmap;
> +
> /* bits in flags of vmalloc's vm_struct below */
> #define VM_IOREMAP 0x00000001 /* ioremap() and friends */
> #define VM_ALLOC 0x00000002 /* vmalloc() */
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ae00746..7f35fe2 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -31,6 +31,7 @@
> #include<asm/tlbflush.h>
> #include<asm/shmparam.h>
>
> +bool vmap_lazy_unmap __read_mostly = true;
>
> /*** Page table manipulation functions ***/
>
> @@ -502,6 +503,9 @@ static unsigned long lazy_max_pages(void)
> {
> unsigned int log;
>
> + if (!vmap_lazy_unmap)
> + return 0;
> +
> log = fls(num_online_cpus());
>
> return log * (32UL * 1024 * 1024 / PAGE_SIZE);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Konrad Rzeszutek Wilk on 27 Jul 2010 14:20
On Tue, Jul 27, 2010 at 06:24:39PM +1000, Nick Piggin wrote:
> On Mon, Jul 26, 2010 at 01:24:51PM -0700, Jeremy Fitzhardinge wrote:
> >
> >
> > [ Nick, I forget if I sent this to you before. Could you Ack it if it looks OK? Thanks, J ]
> >
> > Add a flag to force lazy_max_pages() to zero to prevent any outstanding
> > mapped pages. We'll need this for Xen.
>
> You have sent this to me before, probably several times, and I always
> forget about it right as you send it again.
>
> It's no problem merging something like this for Xen, although as you
> know I would love to see an approach where Xen would benefit from
> delayed flushing as well :)

Hey Nick,

So I've posted the patch with your Ack, in this thread
http://lkml.org/lkml/2010/7/27/246. I hope that is OK?

I think that using the delayed flushing is appropiate long-term.
I don't know that much about it but I will put it on the list of todo.
Fortunatly that list is actually shrinking (amazing!).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 27 Jul 2010 15:00
On 07/27/2010 01:24 AM, Nick Piggin wrote:
> On Mon, Jul 26, 2010 at 01:24:51PM -0700, Jeremy Fitzhardinge wrote:
>>
>> [ Nick, I forget if I sent this to you before. Could you Ack it if it looks OK? Thanks, J ]
>>
>> Add a flag to force lazy_max_pages() to zero to prevent any outstanding
>> mapped pages. We'll need this for Xen.
> You have sent this to me before, probably several times, and I always
> forget about it right as you send it again.
>
> It's no problem merging something like this for Xen, although as you
> know I would love to see an approach where Xen would benefit from
> delayed flushing as well :)

Yes indeed, that would be nice to get. What it comes down to is we need
to be able to flush any lazy vunmap aliases from within interrupt
context, but the code really isn't set up to do that, and last time I
tried to understand that code I couldn't see a straightforward way to
make it work. It would also be nice to have a way to shoot down the
aliases for a specific page, assuming that's any more efficient than
flushing everything.

I don't think anything has changed since we last talked about this.

> You will need to disable lazy flushing from the per-cpu allocator
> (vm_map_ram/vm_unmap_ram, which are used by XFS now). That's not
> tied to the lazy_max stuff (which it should be, arguably)

Ah, OK. I should really add xfs to our roster of regularly tested
filesystems, since it seems to play the most games. Do you know of any
other filesystems which do that kind of thing?

> That code basically allocates per-cpu chunks of va from the global
> allocator, uses them, then frees them back to the global allocator
> all without doing any TLB flushing.
>
> If you have to do global TLB flushing there, then it's probably not
> much value in per-cpu locking of the address allocator anyway, so
> you could just add a test for vmap_lazy_unmap in these branches:
>
> if (likely(count<= VMAP_MAX_ALLOC)&& !vmap_lazy_unmap)

We don't need to do any tlb flushing in these cases, because we're
concerned about making sure we know what ptes a given page is mapped
by. The hypervisor will do any tlb flushing it requires to maintain its
own invariants (so, for example, we can't use a stale tlb entry to keep
accessing a page we've given back to Xen).

Thanks,
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: (none)
Next: [PATCH] lib/scatterlist: Hook sg_kmalloc into kmemleak (v2)