Messages in this thread | | | Date | Mon, 16 Jan 2006 15:57:47 +0000 | From | Andy Whitcroft <> | Subject | Re: [PATCH] BUG: gfp_zone() not mapping zone modifiers correctly and bad ordering of fallback lists |
| |
I think we need to be careful here. Although the __GFP_* modifiers appear to be directly convertable to ZONE_* types they don't have to be. We could potentially have a new modifier which would want to specify a different list combination whilst not representing a zone in and of itself; for example __GFP_NODEONLY which might request use of zones which are NUMA node local. The bits covered by GFP_ZONEMASK represent 'zone modifier space', those GFP bits which affect where we should try and get memory. The zonelists correspond to the lists of zones to try for that combination in 'zone modifier space' not for a specific zone.
Right now there is a near one-to-one correspondance between the __GFP_x and ZONE_x identifiers. As more zones are added we exponentially waste more and more 'zone modifier space' to allow for the possible combinations. If we are willing and able to assert that only one memory zone related modifier is valid at once we could deliberatly squash the zone number into the bottom corner of 'zone modifier space' whilst still maintaining that space and the ability to allow new bits to be combined with it.
My feeling is that as long as we don't lose the ability to have modifiers combine and select separate lists and there is currently no use of combined zone modifiers then we can make this optimisation.
Comments?
-apw
- 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/
| |