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 from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
