> 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
