On Tue, Jan 28, 2020 at 02:07:10PM -0500, Qian Cai wrote:

On Jan 28, 2020, at 12:47 PM, Catalin Marinas [off-list ref] wrote:

quoted

The primary goal here is not finding regressions but having clearly
defined semantics of the page table accessors across architectures. x86
and arm64 are a good starting point and other architectures will be
enabled as they are aligned to the same semantics.

This still does not answer the fundamental question. If this test is
simply inefficient to find bugs,

Who said this is inefficient (other than you)?

who wants to spend time to use it regularly? 

Arch maintainers, mm maintainers introducing new macros or assuming
certain new semantics of the existing macros.

If this is just one off test that may get running once in a few years
(when introducing a new arch), how does it justify the ongoing cost to
maintain it?

You are really missing the point. It's not only for a new arch but
changes to existing arch code. And if the arch code churn in this area
is relatively small, I'd expect a similarly small cost of maintaining
this test.

If you only turn DEBUG_VM on once every few years, don't generalise this
to the rest of the kernel developers (as others pointed out, this test
is default y if DEBUG_VM).

Anyway, I think that's a pointless discussion, so not going to reply
further (unless you have technical content to add).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel