RE: [External] Re: [PATCH v1] include/linux/gfp.h: getting rid of GFP_ZONE_TABLE/BAD

[Huaisheng HS1 Ye]

> From: Matthew Wilcox [mailto:willy@xxxxxxxxxxxxx]
> Sent: Saturday, May 12, 2018 10:23 PM> 
> On Sat, May 12, 2018 at 11:35:00AM +0000, Huaisheng HS1 Ye wrote:
> > > The point of this exercise is to actually encode the zone number in
> > > the bottom bits of the GFP flags instead of something which has to be
> > > interpreted into a zone number.  When somebody sets __GFP_MOVABLE, they
> > > should also be setting ZONE_MOVABLE:
> > >
> > > -#define __GFP_MOVABLE   ((__force gfp_t)___GFP_MOVABLE)  /* ZONE_MOVABLE allowed
> */
> > > +#define __GFP_MOVABLE   ((__force gfp_t)(___GFP_MOVABLE | (ZONE_MOVABLE ^
> ZONE_NORMAL)))
> > >
> > I am afraid we couldn't do that, because __GFP_MOVABLE would be used potentially
> with other __GFPs like __GFP_DMA and __GFP_DMA32.
> 
> That's not a combination that makes much sense.  I know it's permitted today
> (and it has the effect of being a no-op), but when you think about it, it
> doesn't actually make any sense.

Yes, you are right.
After checking almost all references of __GFP_MOVABLE and other __GFP_* flags, perhaps I was far to get excessive pursuit of logical correctness.
For those nonsense combinations, I should ignore them.
Current GFP_ZONE_TABLE can ensure all logical correctness. That makes me want to pursue same effect.

Next, I will revise the patch according to your advice, then try to get overall testing result as far as possible.
There are many combinations because of a lot of conditions in file system and drivers. Hope I could test all things related to the lower 4 bits of gfp.

Sincerely,
Huaisheng Ye