Messages in this thread | | | Date | Mon, 7 Nov 2005 22:22:24 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH]: Cleanup of __alloc_pages |
| |
Nick wrote: > Because it is on the other side of an &&, which evaulates to a > constant zero when !CONFIG_CPUSETS.
Ah so.
> Having __GFP_HIGH as its own flag gives some more flexibility. I > don't think it has a downside?
With respect to GFP_ATOMIC, __GFP_HIGH has no flexibility, as they are #defined to be the same thing.
With respect to __GFP_WAIT, if we only ever use it exactly when we don't use __GFP_HIGH aka GFP_ATOMIC, then there is a definite downside. My old brain doesn't fold constants nearly as reliably or rapidly as a compiler. Every apparent degree of freedom that is unused wastes a few of my remaining precious neurons understanding it. It directly leads to such bugs as the one I noted in my last reply, when I realized that checking cpusets in the 'ignoring mins' case was bogus.
__GFP_HIGH has a second cost - it is easily confused with __GFP_HIGHMEM.
> That would be good. I'll send off a fresh patch with the > ALLOC_WATERMARKS fixed after Rohit gets around to looking over > it.
Good.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |