On Mon, 2020-11-30 at 11:00 +0100, Michal Hocko wrote: > On Fri 27-11-20 14:03:39, Rik van Riel wrote: > > On Fri, 2020-11-27 at 08:52 +0100, Michal Hocko wrote: > > > On Thu 26-11-20 13:04:14, Rik van Riel wrote: > > > > I would be more than happy to implement things differently, > > > > but I am not sure what alternative you are suggesting. > > > > > > Simply do not alter gfp flags? Or warn in some cases of a serious > > > mismatch. > > > E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL > > > users > > > of > > > shmem. > > > > Not altering the gfp flags is not really an option, > > because that would leads to attempting to allocate THPs > > with GFP_HIGHUSER, which is what is used to allocate > > regular tmpfs pages. > > Right but that is a completely different reason to alter the mask and > it > would be really great to know whether this is a theoretical concern > or > those users simply do not ever use THPs. Btw. should they be using > THPs > even if they opt themselves into GFP_KERNEL restriction? I suppose disabling THPs completely if the gfp_mask passed to shmem_getpage_gfp() is not GFP_HIGHUSER is another option. That seems like it might come with its own pitfalls, though, both functionality wise and maintenance wise. Does anyone have strong feelings between "limit gfp_mask" and "disable THP for !GFP_HIGHUSER"? -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
