Messages in this thread | | | Date | Sun, 16 Oct 2005 21:44:18 +0100 (IST) | From | Mel Gorman <> | Subject | Re: [PATCH 2/8] Fragmentation Avoidance V17: 002_usemap |
| |
On Thu, 13 Oct 2005, Dave Hansen wrote:
> > > > + * RCLM_SHIFT is the number of bits that a gfp_mask has to be shifted right > > > > + * to have just the __GFP_USER and __GFP_KERNRCLM bits. The static check is > > > > + * made afterwards in case the GFP flags are not updated without updating > > > > + * this number > > > > + */ > > > > +#define RCLM_SHIFT 19 > > > > +#if (__GFP_USER >> RCLM_SHIFT) != RCLM_USER > > > > +#error __GFP_USER not mapping to RCLM_USER > > > > +#endif > > > > +#if (__GFP_KERNRCLM >> RCLM_SHIFT) != RCLM_KERN > > > > +#error __GFP_KERNRCLM not mapping to RCLM_KERN > > > > +#endif > > > > > > Should this really be in page_alloc.c, or should it be close to the > > > RCLM_* definitions? > > > > I can't test it right now, but I think the reason it is here is because > > RCLM_* and __GFP_* are in different headers that are not aware of each > > other. This is the place a static compile-time check can be made. > > Well, they're pretty intricately linked, so maybe they should go in the > same header, no? >
I looked into this more and I did have a good reason for putting them in different headers. The __GFP_* flags have to be defined with the other GFP flags, it just does not make sense otherwise. The RCLM_* flags must be with the definition of struct zone * because there determine the number of free lists that exist in the zone. There is no obvious way to have the RCLM_* and __GFP_* flags in the same place unless mmzone.h includes gfp.h which I seriously doubt we want.
The value of RCLM_SHIFT depends on both __GFP_* and RCLM_* so it needs to be defined in a place that can see both gfp.h and mmzone.h . As page_alloc.c is the only user of RCLM_SHIFT, it made sense to define it there.
Is there a clearer way of doing this? - 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/
| |