linux-numa.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/4] hugetlb: V3 constrain allocation/free based on task mempolicy
@ 2009-07-29 17:54 Lee Schermerhorn
  2009-07-29 17:54 ` [PATCH 1/4] hugetlb: rework hstate_next_node_* functions Lee Schermerhorn
                   ` (4 more replies)
  0 siblings, 5 replies; 12+ messages in thread
From: Lee Schermerhorn @ 2009-07-29 17:54 UTC (permalink / raw)
  To: linux-mm, linux-numa
  Cc: akpm, Mel Gorman, Nishanth Aravamudan, andi, David Rientjes,
	Adam Litke, Andy Whitcroft, eric.whitney

PATCH 0/4 hugetlb: constrain allocation/free based on task mempolicy

I'm sending these out again, slightly revised, for comparison
with a 3rd alternative for controlling where persistent huge
pages are allocated which I'll send out as a separate series.

Against:  2.6.31-rc3-mmotm-090716-1432
atop previously submitted "alloc_bootmem_huge_pages() fix"
[http://marc.info/?l=linux-mm&m=124775468226290&w=4]

This is V3 of a series of patches to constrain the allocation and
freeing of persistent huge pages using the task NUMA mempolicy of
the task modifying "nr_hugepages".  This series is based on Mel
Gorman's suggestion to use task mempolicy.  One of the benefits
of this method is that it does not *require* modification to
hugeadm(8) to use this feature.

V3 factors the "rework" of the hstate_next_node_to_{alloc|free}
functions out of the patch to derive huge pages nodes_allowed
from mempolicy, and moves it before the patch to add nodemasks
to the alloc/free functions.  See patch patch 1/4.

A couple of limitations [still] in this version:

1) I haven't implemented a boot time parameter to constrain the
   boot time allocation of huge pages.  This can be added if
   anyone feels strongly that it is required.

2) I have not implemented a per node nr_overcommit_hugepages as
   David Rientjes and I discussed earlier.  Again, this can be
   added and specific nodes can be addressed using the mempolicy
   as this series does for allocation and free.  However, after
   some experience with the libhugetlbfs test suite, specifically
   attempting to run the test suite constrained by mempolicy and
   a cpuset, I'm thinking that per node overcommit limits might
   not be such a good idea.  This would require an application
   [or the library] to sum the per node limits over the allowed
   nodes and possibly compare to global limits to determine the
   available resources.  Per cpuset limits might work better.
   This are requires more investigation, but this patch series
   doesn't seem to make things worse than they already are in
   this regard.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2009-07-31 18:49 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-29 17:54 [PATCH 0/4] hugetlb: V3 constrain allocation/free based on task mempolicy Lee Schermerhorn
2009-07-29 17:54 ` [PATCH 1/4] hugetlb: rework hstate_next_node_* functions Lee Schermerhorn
2009-07-30 10:40   ` Mel Gorman
2009-07-29 17:55 ` [PATCH 2/4] hugetlb: add nodemask arg to huge page alloc, free and surplus adjust fcns Lee Schermerhorn
2009-07-30 10:49   ` Mel Gorman
2009-07-29 17:55 ` [PATCH 3/4] hugetlb: derive huge pages nodes allowed from task mempolicy Lee Schermerhorn
2009-07-30 11:15   ` Mel Gorman
2009-07-31 18:49     ` Lee Schermerhorn
2009-07-29 17:55 ` [PATCH 4/4] hugetlb: update hugetlb documentation for mempolicy based management Lee Schermerhorn
2009-07-30 11:18 ` [PATCH 0/4] hugetlb: V3 constrain allocation/free based on task mempolicy Mel Gorman
2009-07-30 14:07   ` Lee Schermerhorn
2009-07-30 14:15     ` Mel Gorman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).