On Thu, 10 Sep 2009, Andrew Morton wrote: > > > alloc_nodemask_of_node() has no callers, so I can think of a good fix > > > for these problems. If it _did_ have a caller then I might ask "can't > > > we fix this by moving alloc_nodemask_of_node() into the .c file". But > > > it doesn't so I can't. > > > > > > > It gets a caller in patch 5 of the series in set_max_huge_pages(). > > ooh, there it is. > > So alloc_nodemask_of_node() could be moved into mm/hugetlb.c. > We discussed that, but the consensus was that it specific to mempolicies not hugepages. Perhaps someday it will gain another caller. > > My early criticism of both alloc_nodemask_of_node() and > > alloc_nodemask_of_mempolicy() was that for small CONFIG_NODES_SHIFT (say, > > 6 or less, which covers all defconfigs except ia64), it is perfectly > > reasonable to allocate 64 bytes on the stack in the caller. > > Spose so. But this stuff is only called when userspace reconfigures > via sysfs, so it'll be low bandwidth (one sincerely hopes). > True, but order-0 GFP_KERNEL allocations will loop forever in the page allocator and kill off tasks if it can't allocate memory. That wouldn't necessarily be a cause for concern other than the fact that this tunable is already frequently written when memory is low to reclaim pages. [ If we're really tailoring it only for its current use case, though, the stack could easily support even NODES_SHIFT of 10. ] -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
