On Wed, Feb 10, 2021 at 01:22:28PM -0800, Ira Weiny wrote:

On Wed, Feb 10, 2021 at 06:56:06PM +0000, Matthew Wilcox wrote:

quoted

On Wed, Feb 10, 2021 at 08:29:01AM -0800, Ira Weiny wrote:

quoted

And I thought it was a good idea.  Any file system development should have
tests with DEBUG_VM which should cover Matthew's concern while not having the
overhead in production.  Seemed like a decent compromise?

Why do you think these paths are only used during file system development?

I can't guarantee it but right now most of the conversions I have worked on are
in FS's.

quoted

They're definitely used by networking, by device drivers of all kinds
and they're probably even used by the graphics system.

While developers *should* turn on DEBUG_VM during development, a
shockingly high percentage don't even turn on lockdep.

Honestly, I don't feel strongly enough to argue it.

I checked my devel config and I don't have DEBUG_VM enabled, while I
have a bunch of other debugging options related to locking or other
fine-grained sanity checks. The help text is not very specific what
exactly is being checked other that it hurts performance, so I read it
as that it's for MM developers that change the MM code, while in
filesystem we use the APIs.

However, for the this patchset I'll turn it on all testing instances of
course.

Andrew?  David?  David this is going through your tree so would you feel more
comfortable with 1 or the other?

I think it's a question for MM people, for now I assume it's supposed to
be VM_BUG_ON.