Messages in this thread Patch in this message | | | From | Paul Jackson <> | Date | Sun, 19 Mar 2006 00:57:55 -0800 | Subject | [PATCH] Cpuset: memory_spread_slab drop useless PF_SPREAD_PAGE check |
| |
From: Paul Jackson <pj@sgi.com>
The hook in the slab cache allocation path to handle cpuset memory spreading for tasks in cpusets with 'memory_spread_slab' enabled has a modest performance bug. The hook calls into the memory spreading handler alternate_node_alloc() if either of 'memory_spread_slab' or 'memory_spread_page' is enabled, even though the handler does nothing (albeit harmlessly) for the page case
Fix - drop PF_SPREAD_PAGE from the set of flag bits that are used to trigger a call to alternate_node_alloc().
The page case is handled by separate hooks -- see the calls conditioned on cpuset_do_page_mem_spread() in mm/filemap.c
Signed-off-by: Paul Jackson <pj@sgi.com>
---
mm/slab.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-)
--- 2.6.16-rc6-mm2.orig/mm/slab.c 2006-03-18 17:30:15.254950360 -0800 +++ 2.6.16-rc6-mm2/mm/slab.c 2006-03-18 21:40:42.465283732 -0800 @@ -2835,8 +2835,7 @@ static inline void *____cache_alloc(stru struct array_cache *ac; #ifdef CONFIG_NUMA - if (unlikely(current->flags & (PF_SPREAD_PAGE | PF_SPREAD_SLAB | - PF_MEMPOLICY))) { + if (unlikely(current->flags & (PF_SPREAD_SLAB | PF_MEMPOLICY))) { objp = alternate_node_alloc(cachep, flags); if (objp != NULL) return objp; @@ -2875,7 +2874,7 @@ static __always_inline void *__cache_all #ifdef CONFIG_NUMA /* - * Try allocating on another node if PF_SPREAD_PAGE|PF_SPREAD_SLAB|PF_MEMPOLICY. + * Try allocating on another node if PF_SPREAD_SLAB|PF_MEMPOLICY. * * If we are in_interrupt, then process context, including cpusets and * mempolicy, may not apply and should not be used for allocation policy. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |