Re: [PATCH 5/5] [hugetlb] Try to grow pool for MAP_SHARED mappings

["Ken Chen" <kenchen@google.com>]

On 7/13/07, Paul Jackson <pj@sgi.com> wrote:
> But the cpuset behaviour of this hugetlb stuff looks suspicious to me:
>  1) The code in alloc_fresh_huge_page() seems to round robin over
>     the entire system, spreading the hugetlb pages uniformly on all nodes.
>     If one a task in one small cpuset starts aggressively allocating hugetlb
>     pages, do you think this will work,

alloc_fresh_huge_page() is used to fill up the hugetlb page pool.  It
is called through sysctl path.  The path that dish out page out of the
pool and allocate to task is alloc_huge_page(), which should obey both
mempolicy and cpuset constrain.


>  2) I don't see what keeps us from picking hugetlb pages off -any- node in the
>     system, perhaps way outside the current cpuset.

I think it is checked in dequeue_huge_page():

                if (cpuset_zone_allowed_softwall(*z, GFP_HIGHUSER) &&
                    !list_empty(&hugepage_freelists[nid]))
                        break;

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