Re: [PATCH] GFP_THISNODE for the slab allocator

[Paul Jackson <pj@sgi.com>]

Thanks for doing this, David.

> I used numa=fake=64 for 64 nodes of 48M each (with my numa=fake fix).  I 
> created a 2G cpuset with 43 nodes (43*48M = ~2G) and attached 'usemem -m 
> 1500 -s 10000000 &' to it for 1.5G of anonymous memory.  I then used 
> readprofile to time and profile a kernel build of 2.6.18-rc5 with x86_64 
> defconfig in the remaining 21 nodes.

I got confused here.  Was the kernel build running in the
2G cpuset (which only had 0.5G remaining free), or was it
running on the remaining 21 nodes, outside the 2G cpuset?

Separate question - would it be easy to run this again, with
a little patch from me that open coded cpuset_zone_allowed()
in get_page_from_freelist()?  The patch I have in mind would
not be acceptable for the real kernel, but it would give us
an idea of whether just a local code change might be sufficient
here.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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>