On Thu 23-06-16 08:58:16, Dave Chinner wrote:

On Wed, Jun 22, 2016 at 02:38:22PM +0200, Michal Hocko wrote:

quoted

On Wed 22-06-16 11:03:20, Dave Chinner wrote:

quoted

On Tue, Jun 21, 2016 at 04:26:28PM +0200, Michal Hocko wrote:

quoted

On Wed 15-06-16 17:21:54, Dave Chinner wrote:

[...]

quoted

quoted

quoted

There are allocations outside transaction context which need to be
GFP_NOFS - this is what KM_NOFS was originally intended for.

Is it feasible to mark those by the scope NOFS api as well and drop
the direct KM_NOFS usage? This should help to identify those that are
lockdep only and use the annotation to prevent from the false positives.

I don't understand what you are suggesting here. This all started
because we use GFP_NOFS in a handful of places to shut up lockdep
and you didn't want us to use GFP_NOFS like that. Now it sounds to
me like you are advocating setting unconditional GFP_NOFS allocation
contexts for entire XFS code paths - whether it's necessary or
not - to avoid problems with lockdep false positives.

No, I meant only those paths which need GFP_NOFS for other than lockdep
purposes would use the scope api.

Anyway, it seems that we are not getting closer to a desired solution
here. Or I am not following it at least...

It seems that we have effectively two possibilities (from the
MM/lockdep) POV. Either add an explicit API to disable the reclaim
lockdep machinery for all allocation in a certain scope or a GFP mask
to to achieve the same for a particular allocation. Which one would work
better for the xfs usecase?

As I've said - if we annotate the XFS call sites appropriately (e.g.
KM_NOLOCKDEP rather than KM_NOFS), we don't care what lockdep
mechanism is used to turn off warnings as it will be wholly
encapsulated inside kmem_alloc() and friends.  This will end up
similar to how we are currently encapsulate the memalloc_noio_save()
wrappers in kmem_zalloc_large().

OK, I see. So which way do we go Peter? Are you going to send the GFP
one or is there a way to bribe you to go with a thread flag?

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>