On Wed 27-04-16 11:41:51, Andreas Dilger wrote:
> On Apr 27, 2016, at 5:54 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
[...]
> > --- a/fs/xfs/kmem.c
> > +++ b/fs/xfs/kmem.c
> > @@ -80,13 +80,13 @@ kmem_zalloc_large(size_t size, xfs_km_flags_t flags)
> > * context via PF_MEMALLOC_NOIO to prevent memory reclaim re-entering
> > * the filesystem here and potentially deadlocking.
> > */
> > - if ((current->flags & PF_FSTRANS) || (flags & KM_NOFS))
> > + if ((current->flags & PF_MEMALLOC_NOFS) || (flags & KM_NOFS))
> > noio_flag = memalloc_noio_save();
> >
> > lflags = kmem_flags_convert(flags);
> > ptr = __vmalloc(size, lflags | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
> >
> > - if ((current->flags & PF_FSTRANS) || (flags & KM_NOFS))
> > + if ((current->flags & PF_MEMALLOC_NOFS) || (flags & KM_NOFS))
> > memalloc_noio_restore(noio_flag);
>
> Not really the fault of this patch, but it brings this nasty bit of code into
> the light. Is all of this machinery still needed given that __vmalloc() can
> accept GFP flags? If yes, wouldn't it be better to fix __vmalloc() to honor
> the GFP flags instead of working around it in the filesystem code?
This is not that easy. __vmalloc can accept gfp flags but it doesn't
honor __GFP_IO 100%. IIRC some paths like page table allocations are
hardcoded GFP_KERNEL. Besides that I would like to have GFP_NOIO used
via memalloc_noio_{save,restore} API as well for the similar reasons as
GFP_NOFS - it is just easier to explain scope than particular code paths
which might be shared.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>