user/sven/linux.git/Documentation/vm/locking, branch v3.0.76

mm: Convert i_mmap_lock to a mutex

2011-05-25T15:39:18Z

Straightforward conversion of i_mmap_lock to a mutex. Signed-off-by: Peter Zijlstra Acked-by: Hugh Dickins Cc: Benjamin Herrenschmidt Cc: David Miller Cc: Martin Schwidefsky Cc: Russell King Cc: Paul Mundt Cc: Jeff Dike Cc: Richard Weinberger Cc: Tony Luck Cc: KAMEZAWA Hiroyuki Cc: Mel Gorman Cc: KOSAKI Motohiro Cc: Nick Piggin Cc: Namhyung Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

truncate: new helpers

2009-09-24T12:41:47Z

Introduce new truncate helpers truncate_pagecache and inode_newsize_ok. vmtruncate is also consolidated from mm/memory.c and mm/nommu.c and into mm/truncate.c. Reviewed-by: Christoph Hellwig Signed-off-by: Nick Piggin Signed-off-by: Al Viro

[PATCH] swap: swap_lock replace list+device

2005-09-05T07:05:42Z

The idea of a swap_device_lock per device, and a swap_list_lock over them all, is appealing; but in practice almost every holder of swap_device_lock must already hold swap_list_lock, which defeats the purpose of the split. The only exceptions have been swap_duplicate, valid_swaphandles and an untrodden path in try_to_unuse (plus a few places added in this series). valid_swaphandles doesn't show up high in profiles, but swap_duplicate does demand attention. However, with the hold time in get_swap_pages so much reduced, I've not yet found a load and set of swap device priorities to show even swap_duplicate benefitting from the split. Certainly the split is mere overhead in the common case of a single swap device. So, replace swap_list_lock and swap_device_lock by spinlock_t swap_lock (generally we seem to prefer an _ in the name, and not hide in a macro). If someone can show a regression in swap_duplicate, then probably we should add a hashlock for the swap_map entries alone (shorts being anatomic), so as to help the case of the single swap device too. Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Convert i_shared_sem back to a spinlock

2004-05-22T15:02:36Z

Having a semaphore in there causes modest performance regressions on heavily mmap-intensive workloads on some hardware. Specifically, up to 30% in SDET on NUMAQ and big PPC64. So switch it back to being a spinlock. This does mean that unmap_vmas() needs to be told whether or not it is allowed to schedule away; that's simple to do via the zap_details structure. This change means that there will be high scheuling latencies when someone truncates a large file which is currently mmapped, but nobody does that anyway. The scheduling points in unmap_vmas() are mainly for munmap() and exit(), and they still will work OK for that. From: Hugh Dickins Sorry, my premature optimizations (trying to pass down NULL zap_details except when needed) have caught you out doubly: unmap_mapping_range_list was NULLing the details even though atomic was set; and if it hadn't, then zap_pte_range would have missed free_swap_and_cache and pte_clear when pte not present. Moved the optimization into zap_pte_range itself. Plus massive documentation update. From: Hugh Dickins Here's a second patch to add to the first: mremap's cows can't come home without releasing the i_mmap_lock, better move the whole "Subtle point" locking from move_vma into move_page_tables. And it's possible for the file that was behind an anonymous page to be truncated while we drop that lock, don't want to abort mremap because of VM_FAULT_SIGBUS. (Eek, should we be checking do_swap_page of a vm_file area against the truncate_count sequence? Technically yes, but I doubt we need bother.) - We cannot hold i_mmap_lock across move_one_page() because move_one_page() needs to perform __GFP_WAIT allocations of pagetable pages. - Move the cond_resched() out so we test it once per page rather than only when move_one_page() returns -EAGAIN.

[PATCH] update Kanoj Sarcar email address in docs

2003-10-05T04:32:15Z

From: Ed L Cashin (Acked by Kanoj Sarcar )

[PATCH] 2.5.63 loose pedantry; loose -> lose where appropriate.

2003-02-24T13:02:46Z

This patch replaces "loose" with "lose" where appropriate. There remain 56 correct uses of "loose" in the 2.5 kernel source.

[PATCH] turn i_shared_lock into a semaphore

2003-01-11T02:39:36Z

i_shared_lock is held for a very long time during vmtruncate() and causes high scheduling latencies when truncating a file which is mmapped. I've seen 100 milliseconds. So turn it into a semaphore. It nests inside mmap_sem. This change is also needed by the shared pagetable patch, which needs to unshare pte's on the vmtruncate path - lots of pagetable pages need to be allocated and they are using __GFP_WAIT. The patch also makes unmap_vma() static.

cachetlb.txt, locking, fork.c, mremap.c, mprotect.c, memory.c:

2002-04-23T12:19:51Z

Make sure that flush_tlb_range is called with PTL held. Also, make sure no new threads can start up in user mode while a tlb_gather_mmu is in progress.

v2.4.2.4 -> v2.4.2.5

2002-02-05T02:03:57Z

- Rik van Riel and others: mm rw-semaphore (ps/top ok when swapping) - IDE: 256 sectors at a time is legal, but apparently confuses some drives. Max out at 255 sectors instead. - Petko Manolov: USB pegasus driver update - make the boottime memory map printout at least almost readable. - USB driver updates - pte_alloc()/pmd_alloc() need page_table_lock.

Import changeset

2002-02-05T01:40:40Z