[lkml]   [2018]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [External] Re: [PATCH v1] include/linux/gfp.h: getting rid of GFP_ZONE_TABLE/BAD
> From: Matthew Wilcox []
> 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 ^
> > >
> > 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.

Huaisheng Ye

 \ /
  Last update: 2018-05-16 14:15    [W:0.075 / U:6.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site