Re: [LSF/MM ATTEND] 2017 userfaultfd-WP, node reclaim vs zone compaction, THP
From: Mike Kravetz <hidden>
Date: 2017-01-26 17:50:31
On 01/12/2017 11:26 AM, Andrea Arcangeli wrote:
Hello, I'd like to attend this year LSF/MM summit. Some topics of my interest would be: 1) userfaultfd WP and soft-dirty interaction (i.e. obsolete soft-dirty). Arch-dependent changes are required for this: from one-more VM_FAULT_RETRY in a row to be returned by handle_mm_fault, to a special bit in pagetable and swap entry, very similarly to what soft dirty has been doing. The main rationale to eventually obsolete soft-dirty is that userfaultfd WP won't require O(N) pagetable scans to find out which pages got dirty (where N is the number of pagetables mapping the region to be monitored, not the number of pages that got dirty). userfaultfd will have the same runtime cost regardless of the size of the area to be monitored for writes, similar to PML (Page Modification Logging) feature in the CPU for VMX. soft-dirty is also triggering write protect faults, the only advantage it has for some usage (which is a disadvantage for other usages like database/KVM live snapshotting) is it's asynchronous, but userfaultfs can also add an asynchronous feature mode later by allocating and queuing up uffd messages, instead of blocking the tasks. If there's interested I could also summarize the current userfaultfd status with hugetlbfs/shmem/non-cooperative support currently merged in -mm.
I would be interested in the WP discussion as well. When adding hugetlbfs support to userfaultfd, I briefly looked at the state of WP code and the interaction with soft dirty. It would be good to discuss these general issues. -- Mike Kravetz
2) the s/zone/node/ conversion of the page LRU feels still incomplete,
as compaction still works zone based and can't compact memory
crossing the zone boundaries. While it's is simpler to do
compaction that way, it's not ideal because reclaim works node
based.
To avoid dropping some patches that implement "compaction aware
zone_reclaim_mode" (i.e. now node_reclaim_mode) I'm still running
with zone LRU, although I don't disagree with the node LRU per se,
my only issue is that compaction still work zone based and that
collides with those changes.
With reclaim working node based and compaction working zone
based, I would need to call a blind for_each_zone(node)
compaction() loop which is far from ideal compared to compaction
crossing the zone boundary. Most pages that can be migrated by
compaction can go in any zone, not all but we could record the page
classzone.
On a side note just yesterday I got this message from kbuild bot:
---
FYI, we noticed a 7.2% improvement of pbzip2.throughput due to commit:
commit: 59ebc9c2dff1bd6476f621e1c9802dc40c8c5e98 ("Revert
"mm/page_alloc.c: recalculate some of node threshold when
on/offline memory"")
https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git master
---
This may be a statistical blip, I didn't investigate why zone LRU
should be faster for this test but I assume kbuild is reliable and
the result reproducible.
3) I'm always interested in the THP related developments, from native
swapout (perhaps native swapin) to ext4 support etc..
Thank you,
Andrea
--
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>-- 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>