On Fri, 11 Sep 2009, Lee Schermerhorn wrote: > > It's a bit rude to assume that the caller wanted to use GFP_KERNEL. > > I can add a gfp_t parameter to the macro, but I'll still need to select > value in the caller. Do you have a suggested alternative to GFP_KERNEL > [for both here and in alloc_nodemask_of_mempolicy()]? We certainly > don't want to loop forever, killing off tasks, as David mentioned. > Silently failing is OK. We handle that. > Dynamically allocating the nodemask_t for small NODES_SHIFT and failing to find adequate memory isn't as troublesome as I may have made it sound; it's only a problem if we're low on memory and can't do order-0 GFP_KERNEL allocations and the kmalloc cache for that size is full. That's going to be extremely rare, but the first requirement, being low on memory, is one of the reasons why people traditionally free hugepages via the tunable. As far as the software engineering of alloc_nodemask_of_node() goes, I'd defer back to my previous suggestion of modifying NODEMASK_ALLOC() which has very much the same purpose. It's also only used with mempolicies because we're frequently dealing with the same issue; this is not unique only to hugetlb, which is probably why it was made generic in the first place. It has the added benefit of also incorporating my other suggestion, which was to allocate these on the stack when NODES_SHIFT is small, which it defaults to for all architectures other than ia64. I think it would be nice to avoid the slab allocator for relatively small (<= 256 bytes?) amounts of memory that could otherwise be stack allocated. That's more of a general statement with regard to the entire kernel, but I don't think you'll find much benefit in always allocating them from slab for code clarity when NODEMASK_ALLOC() exists for the same purpose such as set_mempolicy(), mbind(), etc. So I'd ask that you reconsider using NODEMASK_ALLOC() by making it more general (i.e. not just allocating "structs of <name>" but rather pass in the entire type such as "nodemask_t" or "struct nodemask_scratch") and then using it to dynamically allocate your hugetlb nodemasks when necessary because of their size. -- 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
