On 02.07.21 00:11, David Matlack wrote:
On Thu, Jul 01, 2021 at 07:00:51PM +0200, David Hildenbrand wrote:
On 30.06.21 23:47, David Matlack wrote:
This patch series adds support for the TDP MMU in the fast_page_fault
path, which enables certain write-protection and access tracking faults
to be handled without taking the KVM MMU lock. This series brings the
performance of these faults up to par with the legacy MMU.
Since there is not currently any KVM test coverage for access tracking
faults, this series introduces a new KVM selftest,
access_tracking_perf_test. Note that this test relies on page_idle to
enable access tracking from userspace (since it is the only available
usersapce API to do so) and page_idle is being considered for removal
from Linux
(https://lore.kernel.org/linux-mm/20210612000714.775825-1-willy@xxxxxxxxxxxxx/).
Well, at least a new selftest that implicitly tests a part of page_idle --
nice :)
Haven't looked into the details, but if you can live with page tables
starting unpopulated and only monitoring what gets populated on r/w access,
you might be able to achieve something similar using /proc/self/pagemap and
softdirty handling.
Unpopulated page (e.g., via MADV_DISCARD) -> trigger read or write access ->
sense if page populated in pagemap
Populated page-> clear all softdirty bits -> trigger write access -> sense
if page is softdirty in pagemap
Thanks for the suggestion. I modified by test to write 4 to
/proc/self/clear_refs rather than marking pages in page_idle. However,
by doing so I was no longer able to exercise KVM's fast_page_fault
handler [1].
It looks like the reason why is that clear_refs issues the
invalidate_range mmu notifiers, which will cause KVM to fully refault
the page from the host MM upon subsequent guest memory accesses. In
contrast, page_idle uses clear_young which KVM can handle with
fast_page_fault.
Right, the only thing you could provoke may be (again, did not look into
the details):
1. 4 > /proc/self/clear_refs to clear all softdirty bits
2. Trigger a read fault. This will populate the shared zeropage on
private anonymous memory and populate an actual page on e.g., shmem.
3. Trigger a write fault. This should result in a COW fault on private
anonymous memory and (IIRC) a WP-fault on shmem.
The COW on private anonymous memory would invalidate the secondary MMU
again via MMU notifiers I guess, so it's not what we want. It *might*
work on shmem, I might be wrong, though.
But again, I haven't looked into the details/checked the code and we
might actually not be able to test with softdirty at all. IMHO, page
idle tracking might be good enough for a test.
Consider it rather a brain dump than a suggestion ;)
--
Thanks,
David / dhildenb
