Re: [PATCH v2 00/20] Speculative page faults

From: Anshuman Khandual
Date: Mon Aug 21 2017 - 02:28:30 EST

On 08/18/2017 03:34 AM, Laurent Dufour wrote:
> This is a port on kernel 4.13 of the work done by Peter Zijlstra to
> handle page fault without holding the mm semaphore [1].
>
> The idea is to try to handle user space page faults without holding the
> mmap_sem. This should allow better concurrency for massively threaded
> process since the page fault handler will not wait for other threads memory
> layout change to be done, assuming that this change is done in another part
> of the process's memory space. This type page fault is named speculative
> page fault. If the speculative page fault fails because of a concurrency is
> detected or because underlying PMD or PTE tables are not yet allocating, it
> is failing its processing and a classic page fault is then tried.
>
> The speculative page fault (SPF) has to look for the VMA matching the fault
> address without holding the mmap_sem, so the VMA list is now managed using
> SRCU allowing lockless walking. The only impact would be the deferred file
> derefencing in the case of a file mapping, since the file pointer is
> released once the SRCU cleaning is done. This patch relies on the change
> done recently by Paul McKenney in SRCU which now runs a callback per CPU
> instead of per SRCU structure [1].
>
> The VMA's attributes checked during the speculative page fault processing
> have to be protected against parallel changes. This is done by using a per
> VMA sequence lock. This sequence lock allows the speculative page fault
> handler to fast check for parallel changes in progress and to abort the
> speculative page fault in that case.
>
> Once the VMA is found, the speculative page fault handler would check for
> the VMA's attributes to verify that the page fault has to be handled
> correctly or not. Thus the VMA is protected through a sequence lock which
> allows fast detection of concurrent VMA changes. If such a change is
> detected, the speculative page fault is aborted and a *classic* page fault
> is tried. VMA sequence locks are added when VMA attributes which are
> checked during the page fault are modified.
>
> When the PTE is fetched, the VMA is checked to see if it has been changed,
> so once the page table is locked, the VMA is valid, so any other changes
> leading to touching this PTE will need to lock the page table, so no
> parallel change is possible at this time.
>
> Compared to the Peter's initial work, this series introduces a spin_trylock
> when dealing with speculative page fault. This is required to avoid dead
> lock when handling a page fault while a TLB invalidate is requested by an
> other CPU holding the PTE. Another change due to a lock dependency issue
> with mapping->i_mmap_rwsem.
>
> In addition some VMA field values which are used once the PTE is unlocked
> at the end the page fault path are saved into the vm_fault structure to
> used the values matching the VMA at the time the PTE was locked.
>
> This series builds on top of v4.13-rc5 and is functional on x86 and
> PowerPC.
>
> Tests have been made using a large commercial in-memory database on a
> PowerPC system with 752 CPU using RFC v5. The results are very encouraging
> since the loading of the 2TB database was faster by 14% with the
> speculative page fault.
>

You specifically mention loading as most of the page faults will
happen at that time and then the working set will settle down with
very less page faults there after ? That means unless there is
another wave of page faults we wont notice performance improvement
during the runtime.

> Using ebizzy test [3], which spreads a lot of threads, the result are good
> when running on both a large or a small system. When using kernbench, the

The performance improvements are greater as there is a lot of creation
and destruction of anon mappings which generates constant flow of page
faults to be handled.

> result are quite similar which expected as not so much multi threaded
> processes are involved. But there is no performance degradation neither
> which is good.

If we compile with 'make -j N' there would be a lot of threads but I
guess the problem is SPF does not support handling file mapping IIUC
which limits the performance improvement for some workloads.

>
> ------------------
> Benchmarks results
>
> Note these test have been made on top of 4.13-rc3 with the following patch
> from Paul McKenney applied:
> "srcu: Provide ordering for CPU not involved in grace period" [5]

Is this patch an improvement for SRCU which we are using for walking VMAs.

>
> Ebizzy:
> -------
> The test is counting the number of records per second it can manage, the
> higher is the best. I run it like this 'ebizzy -mTRp'. To get consistent
> result I repeated the test 100 times and measure the average result, mean
> deviation, max and min.
>
> - 16 CPUs x86 VM
> Records/s 4.13-rc5 4.13-rc5-spf
> Average 11350.29 21760.36
> Mean deviation 396.56 881.40
> Max 13773 26194
> Min 10567 19223
>
> - 80 CPUs Power 8 node:
> Records/s 4.13-rc5 4.13-rc5-spf
> Average 33904.67 58847.91
> Mean deviation 789.40 1753.19
> Max 36703 68958
> Min 31759 55125
>

Can you also mention % improvement or degradation in a new column.

> The number of record per second is far better with the speculative page
> fault.
> The mean deviation is higher with the speculative page fault, may be
> because sometime the fault are not handled in a speculative way leading to
> more variation.

we need to analyze that. Why speculative page faults failed on those
occasions for exact same workload.

>
>
> Kernbench:
> ----------
> This test is building a 4.12 kernel using platform default config. The
> build has been run 5 times each time.
>
> - 16 CPUs x86 VM
> Average Half load -j 8 Run (std deviation)
> 4.13.0-rc5 4.13.0-rc5-spf
> Elapsed Time 166.574 (0.340779) 145.754 (0.776325)
> User Time 1080.77 (2.05871) 999.272 (4.12142)
> System Time 204.594 (1.02449) 116.362 (1.22974)
> Percent CPU 771.2 (1.30384) 765 (0.707107)
> Context Switches 46590.6 (935.591) 66316.4 (744.64)
> Sleeps 84421.2 (596.612) 85186 (523.041)


>
> Average Optimal load -j 16 Run (std deviation)
> 4.13.0-rc5 4.13.0-rc5-spf
> Elapsed Time 85.422 (0.42293) 74.81 (0.419345)
> User Time 1031.79 (51.6557) 954.912 (46.8439)
> System Time 186.528 (19.0575) 107.514 (9.36902)
> Percent CPU 1059.2 (303.607) 1056.8 (307.624)
> Context Switches 67240.3 (21788.9) 89360.6 (24299.9)
> Sleeps 89607.8 (5511.22) 90372.5 (5490.16)
>
> The elapsed time is a bit shorter in the case of the SPF release, but the
> impact less important since there are less multithreaded processes involved
> here.
>
> - 80 CPUs Power 8 node:
> Average Half load -j 40 Run (std deviation)
> 4.13.0-rc5 4.13.0-rc5-spf
> Elapsed Time 117.176 (0.824093) 116.792 (0.695392)
> User Time 4412.34 (24.29) 4396.02 (24.4819)
> System Time 131.106 (1.28343) 133.452 (0.708851)
> Percent CPU 3876.8 (18.1439) 3877.6 (21.9955)
> Context Switches 72470.2 (466.181) 72971 (673.624)
> Sleeps 161294 (2284.85) 161946 (2217.9)
>
> Average Optimal load -j 80 Run (std deviation)
> 4.13.0-rc5 4.13.0-rc5-spf
> Elapsed Time 111.176 (1.11123) 111.242 (0.801542)
> User Time 5930.03 (1600.07) 5929.89 (1617)
> System Time 166.258 (37.0662) 169.337 (37.8419)
> Percent CPU 5378.5 (1584.16) 5385.6 (1590.24)
> Context Switches 117389 (47350.1) 130132 (60256.3)
> Sleeps 163354 (4153.9) 163219 (2251.27)
>

Can you also mention % improvement or degradation in a new column.

> Here the elapsed time is a bit shorter using the spf release, but we
> remain in the error margin. It has to be noted that this system is not
> correctly balanced on the NUMA point of view as all the available memory is
> attached to one core.

Why different NUMA configuration would have changed the outcome ?

>
> ------------------------
> Changes since v1:
> - Remove PERF_COUNT_SW_SPF_FAILED perf event.
> - Add tracing events to details speculative page fault failures.
> - Cache VMA fields values which are used once the PTE is unlocked at the
> end of the page fault events.

Why is this required ?