vmap: add flag to allow lazy unmap to be disabled at runtime
Subsystems (2)
PATCH 1/1 vmap: add flag to allow lazy unmap to be disabled at runtime
[ 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.
include/linux/vmalloc.h +2 -0
@@ -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() */
mm/vmalloc.c +4 -0
@@ -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 );
Quoted 6 lines · 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.
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
Quoted 39 lines
Signed-off-by Jeremy Fitzhardinge<[email protected]>include/linux/vmalloc.h +2
-0@@ -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() */ mm/vmalloc.c +4
-0@@ -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 );
Quoted 8 lines · Nick Piggin
Quoted 6 lines · 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.
Quoted 6 lines
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!).
Quoted 4 lines · Nick Piggin
Quoted 3 lines · Jeremy Fitzhardinge
[ Nick, I forget if I sent this to you before. Could you Ack it if it looks OK? Thanks, J ]
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
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_maxstuff (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?
Quoted 9 lines
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_unmapin 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