[PATCH] vmap: add flag to allow lazy unmap to be disabled at runtime

[PATCH] vmap: add flag to allow lazy unmap to be disabled at runtime

[Jeremy Fitzhardinge]

[ 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.

Signed-off-by: Jeremy Fitzhardinge<jeremy.fitzhardinge@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);

Re: [PATCH] vmap: add flag to allow lazy unmap to be disabled at runtime

[Nick Piggin]

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@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);
> 

Re: [PATCH] vmap: add flag to allow lazy unmap to be disabled at runtime

[Konrad Rzeszutek Wilk]

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!).

Re: [PATCH] vmap: add flag to allow lazy unmap to be disabled at runtime

[Jeremy Fitzhardinge]

  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