On Fri, Sep 25, 2015 at 01:51:06PM +0100, Mel Gorman wrote:
> On Thu, Sep 24, 2015 at 04:55:09PM -0400, Johannes Weiner wrote:
> > On Mon, Sep 21, 2015 at 11:52:37AM +0100, Mel Gorman wrote:
> > > @@ -119,10 +134,10 @@ struct vm_area_struct;
> > >  #define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
> > >  #define GFP_HIGHUSER     (GFP_USER | __GFP_HIGHMEM)
> > >  #define GFP_HIGHUSER_MOVABLE     (GFP_HIGHUSER | __GFP_MOVABLE)
> > > -#define GFP_IOFS (__GFP_IO | __GFP_FS)
> > > -#define GFP_TRANSHUGE    (GFP_HIGHUSER_MOVABLE | __GFP_COMP | \
> > > -                  __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN | \
> > > -                  __GFP_NO_KSWAPD)
> > > +#define GFP_IOFS (__GFP_IO | __GFP_FS | __GFP_KSWAPD_RECLAIM)
> > 
> > These are some really odd semantics to be given a name like that.
> > 
> > GFP_IOFS was introduced as a short-hand for testing/setting/clearing
> > these two bits at the same time, not to be used for allocations. In
> > fact, the only user for allocations is lustre, and it's not at all
> > obious why those sites shouldn't include __GFP_WAIT as well.
> > 
> > Removing this definition altogether would probably be best.
> 
> Ok, I'll add a TODO to create a patch that removes GFP_IOFS entirely. It
> can be tacked on to the end of the series.

Okay, that makes sense to me. Thanks!

Acked-by: Johannes Weiner <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to