mm: optimize put_mems_allowed() usage
Since put_mems_allowed() is strictly optional, its a seqcount retry, we don't need to evaluate the function if the allocation was in fact successful, saving a smp_rmb some loads and comparisons on some relative fast-paths. Since the naming, get/put_mems_allowed() does suggest a mandatory pairing, rename the interface, as suggested by Mel, to resemble the seqcount interface. This gives us: read_mems_allowed_begin() and read_mems_allowed_retry(), where it is important to note that the return value of the latter call is inverted from its previous incarnation. Signed-off-by:Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Mel Gorman <mgorman@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
Showing
- include/linux/cpuset.h 14 additions, 13 deletionsinclude/linux/cpuset.h
- kernel/cpuset.c 1 addition, 1 deletionkernel/cpuset.c
- mm/filemap.c 2 additions, 2 deletionsmm/filemap.c
- mm/hugetlb.c 2 additions, 2 deletionsmm/hugetlb.c
- mm/mempolicy.c 6 additions, 6 deletionsmm/mempolicy.c
- mm/page_alloc.c 4 additions, 4 deletionsmm/page_alloc.c
- mm/slab.c 2 additions, 2 deletionsmm/slab.c
- mm/slub.c 7 additions, 9 deletionsmm/slub.c
Loading
Please register or sign in to comment