Re: [PATCH] GFP_THISNODE for the slab allocator

[David Rientjes <rientjes@google.com>]

On Sat, 16 Sep 2006, Christoph Lameter wrote:

> One would not construct a memory container from 50 zones but build a 
> single zone as a memory container of that size.
> 

Now I used numa=fake=64 for 64 nodes of 48M each and created a 2G cpuset 
(43 nodes) and attached 'usemem -m 1500 -s 100000000 &' for 1.5G of 
anonymous memory.  Then I timed and profiled the kernel build in the 
remaining 1G on my 3G box (21 nodes).  This was the old case.

I made a modification in my own tree that allowed numa=fake=N to break the 
memory into N nodes that are not powers of 2 (by writing a new hash 
function for pfn_to_nid).  I booted with numa=fake=3 which gives me one 
node of 2G and another of 1G.  I then placed each in their own cpusets and 
repeated the experiment.

		64 nodes		3 nodes
	real	5m19.722s		5m2.171s
	user	9m11.790s		9m15.999s
	sys	1m9.164s		0m31.030s

64 nodes:
	3786 mwait_idle				48.5385
	8590 __cpuset_zone_allowed		40.9048
	 978 clear_page				17.1579
	  22 clear_page_end			 3.1429
	 202 find_get_page			 2.8451
	 115 pfn_to_page			 2.5000
	 355 zone_watermark_ok			 2.2756
	 131 __down_read_trylock		 1.9848
	  86 page_remove_rmap			 1.9545
	 146 find_vma				 1.6782
	...
	1129 get_page_from_freelist		 1.2127

3 nodes:
	3940 mwait_idle				50.5128
	1114 clear_page				19.5439
	  19 clear_page_end			 2.7143
	 184 find_get_page			 2.5915
	  98 page_remove_rmap			 2.2273
	 122 __down_read_trylock		 1.8485
	 140 find_vma				 1.6092
	  67 pfn_to_page			 1.4565
	  47 __strnlen_user			 1.2051
	  24 page_add_file_rmap			 1.0909
	...
	 457 get_page_from_freelist		 0.4909
	  33 lru_cache_add_active		 0.4853
	...
	  90 __cpuset_zone_allowed		 0.4286

		David

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>