On 13 Sep 2020, at 23:31, Matthew Wilcox wrote:
On Mon, Sep 14, 2020 at 09:45:03AM +1000, Dave Chinner wrote:
I have my doubts that complex page cache manipulation operations
like ->migrate_page that rely exclusively on page and internal mm
serialisation are really safe against ->fallocate based invalidation
races. I think they probably also need to be wrapped in the
MMAPLOCK, but I don't understand all the locking and constraints
that ->migrate_page has and there's been no evidence yet that it's a
problem so I've kinda left that alone. I suspect that "no evidence"
thing comes from "filesystem people are largely unable to induce
page migrations in regression testing" so it has pretty much zero
test coverage....
Maybe we can get someone who knows the page migration code to give
us a hack to induce pretty much constant migration?
While debugging migrate page problems, I usually run dbench and
while(true) ; do echo 1 > /proc/sys/vm/compact_memory ; done
I’ll do this with a mixture of memory pressure or drop_caches or a
memory hog depending on what I hope to trigger.
Because of hugepage allocations, we tend to bash on migration/compaction
fairly hard in the fleet. We do fallocate in some of these workloads as
well, but I’m sure it doesn’t count as complete coverage for the
races Dave is worried about.
-chris
