On Mon 25-01-16 15:21:39, Jan Kara wrote:
> Hi!
>
> On Mon 25-01-16 14:33:57, Michal Hocko wrote:
[...
> > Another issue is that GFP_NOFS is quite often used without any obvious
> > reason. It is not clear which lock is held and could be taken from
> > the reclaim path. Wouldn't it be much better if the no-recursion
> > behavior was bound to the lock scope rather than particular allocation
> > request? We already have something like this for PM
> > pm_res{trict,tore}_gfp_mask resp. memalloc_noio_{save,restore}. It
> > would be great if we could unify this and use the context based NOFS
> > in the FS.
>
> I like the idea that we'd protect lock scopes from reclaim recursion but the
> effort to do so would be IMHO rather big. E.g. there are ~75 instances of
> GFP_NOFS allocation in ext4/jbd2 codebase and making sure all are properly
> covered will take quite some auditing... I'm not saying we shouldn't do
> something like this, just you will have to be good in selling the benefits
> :).
My idea was that the first step would be using the helpers to mark
scopes and other usage of the ~__GFP_FS inside such a scope could be
identified much easier (e.g. a debugging WARN_ON or something like
that). That can be done in a longer term. Then I would hope for reducing
GFP_NOFS usage from mapping_gfp_mask.
I realize this is a lot of work but I believe this will pay of long
term. And especially the first step shouldn't be that hard because locks
used from the reclaim path shouldn't be that hard to identify.
GFP_NOFS is a mess these days and it is far from trivial to tell wether
it should be used or not from some paths.
--
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
