Re: [PATCH v9 00/24] Speculative page faults
On 14/03/2018 14:11, Michal Hocko wrote: > On Tue 13-03-18 18:59:30, Laurent Dufour wrote: >> Changes since v8: >> - Don't check PMD when locking the pte when THP is disabled >>Thanks to Daniel Jordan for reporting this. >> - Rebase on 4.16 > > Is this really worth reposting the whole pile? I mean this is at v9, > each doing little changes. It is quite tiresome to barely get to a > bookmarked version just to find out that there are 2 new versions out. > > I am sorry to be grumpy and I can understand some frustration it doesn't > move forward that easilly but this is a _big_ change. We should start > with a real high level review rather than doing small changes here and > there and reach v20 quickly. I know this would mean v10, but there has been a bunch of reviews from David Rientjes and Jerome Glisse, and I had to make many changes to address them. So I think this is time to push a v10. If you have already started a review of this v9 series, please send me your remarks so that I can compile them in this v10 asap. Thanks, Laurent.
Re: [PATCH v9 00/24] Speculative page faults
Hi Jerome, Thanks for reviewing this series. On 03/04/2018 22:37, Jerome Glisse wrote: > On Tue, Mar 13, 2018 at 06:59:30PM +0100, Laurent Dufour wrote: >> This is a port on kernel 4.16 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, this is done by introducing a rwlock >> which protects the access to the mm_rb tree. Previously this was done using >> SRCU but it was introducing a lot of scheduling to process the VMA's >> freeing >> operation which was hitting the performance by 20% as reported by Kemi Wang >> [2].Using a rwlock to protect access to the mm_rb tree is limiting the >> locking contention to these operations which are expected to be in a O(log >> n) >> order. In addition to ensure that the VMA is not freed in our back a >> reference count is added and 2 services (get_vma() and put_vma()) are >> introduced to handle the reference count. When a VMA is fetch from the RB >> tree using get_vma() is must be later freeed using put_vma(). Furthermore, >> to allow the VMA to be used again by the classic page fault handler a >> service is introduced can_reuse_spf_vma(). This service is expected to be >> called with the mmap_sem hold. It checked that the VMA is still matching >> the specified address and is releasing its reference count as the mmap_sem >> is hold it is ensure that it will not be freed in our back. In general, the >> VMA's reference count could be decremented when holding the mmap_sem but it >> should not be increased as holding the mmap_sem is ensuring that the VMA is >> stable. I can't see anymore the overhead I got while will-it-scale >> benchmark anymore. >> >> 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 lockings 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. > > What would have been nice is some pseudo highlevel code before all the > above detailed description. Something like: > speculative_fault(addr) { > mm_lock_for_vma_snapshot() > vma_snapshot = snapshot_vma_infos(addr) > mm_unlock_for_vma_snapshot() > ... > if (!vma_can_speculatively_fault(vma_snapshot, addr)) > return; > ... > /* Do fault ie alloc memory, read from file ... */ > page = ...; > > preempt_disable(); > if (vma_snapshot_still_valid(vma_snapshot, addr) && > vma_pte_map_lock(vma_snapshot, addr)) { > if (pte_same(ptep, orig_pte)) { > /* Setup new pte */ > page = NULL; > } > } > preempt_enable(); > if (page) > put(page) > } > > I just find pseudo code easier for grasping the highlevel view of the > expected code flow. Fair enough, I agree that sounds easier this way, but one might argue that the pseudo code is not more valid or accurate at one time :) As always, the updated documentation is the code itself. I'll try to put one inspired by yours in the next series's header. >> >> The locking of the PTE is done with interrupts disabled, this allows to >> check for the PMD to ensure that there is not an ongoing collapsing >> operation. Since khugepaged is firstly set the PMD to pmd_none and then is >> waiting for the other CPU to have catch the IPI interrupt, if the pmd is >> valid at the time the PTE is locked, we have the
Re: [PATCH v9 00/24] Speculative page faults
On Tue, Mar 13, 2018 at 06:59:30PM +0100, Laurent Dufour wrote: > This is a port on kernel 4.16 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, this is done by introducing a rwlock > which protects the access to the mm_rb tree. Previously this was done using > SRCU but it was introducing a lot of scheduling to process the VMA's > freeing > operation which was hitting the performance by 20% as reported by Kemi Wang > [2].Using a rwlock to protect access to the mm_rb tree is limiting the > locking contention to these operations which are expected to be in a O(log > n) > order. In addition to ensure that the VMA is not freed in our back a > reference count is added and 2 services (get_vma() and put_vma()) are > introduced to handle the reference count. When a VMA is fetch from the RB > tree using get_vma() is must be later freeed using put_vma(). Furthermore, > to allow the VMA to be used again by the classic page fault handler a > service is introduced can_reuse_spf_vma(). This service is expected to be > called with the mmap_sem hold. It checked that the VMA is still matching > the specified address and is releasing its reference count as the mmap_sem > is hold it is ensure that it will not be freed in our back. In general, the > VMA's reference count could be decremented when holding the mmap_sem but it > should not be increased as holding the mmap_sem is ensuring that the VMA is > stable. I can't see anymore the overhead I got while will-it-scale > benchmark anymore. > > 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 lockings 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. What would have been nice is some pseudo highlevel code before all the above detailed description. Something like: speculative_fault(addr) { mm_lock_for_vma_snapshot() vma_snapshot = snapshot_vma_infos(addr) mm_unlock_for_vma_snapshot() ... if (!vma_can_speculatively_fault(vma_snapshot, addr)) return; ... /* Do fault ie alloc memory, read from file ... */ page = ...; preempt_disable(); if (vma_snapshot_still_valid(vma_snapshot, addr) && vma_pte_map_lock(vma_snapshot, addr)) { if (pte_same(ptep, orig_pte)) { /* Setup new pte */ page = NULL; } } preempt_enable(); if (page) put(page) } I just find pseudo code easier for grasping the highlevel view of the expected code flow. > > The locking of the PTE is done with interrupts disabled, this allows to > check for the PMD to ensure that there is not an ongoing collapsing > operation. Since khugepaged is firstly set the PMD to pmd_none and then is > waiting for the other CPU to have catch the IPI interrupt, if the pmd is > valid at the time the PTE is locked, we have the guarantee that the > collapsing opertion will have to wait on the PTE lock to move foward. This > allows the SPF handler to map the PTE safely. If the PMD value is different > than the one recorded at the beginning of the SPF operation, the classic > page fault handler will be called to handle the operation while holding the > mmap_sem. As the PTE lock is done with the interrupts disabled, the lock is > done using spin_trylock() to avoid dead lock when handling a
Re: [PATCH v9 00/24] Speculative page faults
On 22/03/2018 02:21, Ganesh Mahendran wrote: > Hi, Laurent > > 2018-03-14 1:59 GMT+08:00 Laurent Dufour: >> This is a port on kernel 4.16 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, this is done by introducing a rwlock >> which protects the access to the mm_rb tree. Previously this was done using >> SRCU but it was introducing a lot of scheduling to process the VMA's >> freeing >> operation which was hitting the performance by 20% as reported by Kemi Wang >> [2].Using a rwlock to protect access to the mm_rb tree is limiting the >> locking contention to these operations which are expected to be in a O(log >> n) >> order. In addition to ensure that the VMA is not freed in our back a >> reference count is added and 2 services (get_vma() and put_vma()) are >> introduced to handle the reference count. When a VMA is fetch from the RB >> tree using get_vma() is must be later freeed using put_vma(). Furthermore, >> to allow the VMA to be used again by the classic page fault handler a >> service is introduced can_reuse_spf_vma(). This service is expected to be >> called with the mmap_sem hold. It checked that the VMA is still matching >> the specified address and is releasing its reference count as the mmap_sem >> is hold it is ensure that it will not be freed in our back. In general, the >> VMA's reference count could be decremented when holding the mmap_sem but it >> should not be increased as holding the mmap_sem is ensuring that the VMA is >> stable. I can't see anymore the overhead I got while will-it-scale >> benchmark anymore. >> >> 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 lockings 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. >> >> The locking of the PTE is done with interrupts disabled, this allows to >> check for the PMD to ensure that there is not an ongoing collapsing >> operation. Since khugepaged is firstly set the PMD to pmd_none and then is >> waiting for the other CPU to have catch the IPI interrupt, if the pmd is >> valid at the time the PTE is locked, we have the guarantee that the >> collapsing opertion will have to wait on the PTE lock to move foward. This >> allows the SPF handler to map the PTE safely. If the PMD value is different >> than the one recorded at the beginning of the SPF operation, the classic >> page fault handler will be called to handle the operation while holding the >> mmap_sem. As the PTE lock is done with the interrupts disabled, the lock is >> done using spin_trylock() to avoid dead lock when handling a page fault >> while a TLB invalidate is requested by an other CPU holding the PTE. >> >> Support for THP is not done because when checking for the PMD, we can be >> confused by an in progress collapsing operation done by khugepaged. The >> issue is that pmd_none() could be true either if the PMD is not already >> populated or if the underlying PTE are in the way to be collapsed. So we >> cannot safely allocate a PMD if pmd_none() is true. >> >> This series a new software performance event named 'speculative-faults' or >> 'spf'. It counts the number of successful page fault event handled in a >> speculative way. When recording 'faults,spf' events, the faults one is >>
Re: [PATCH v9 00/24] Speculative page faults
Hi, Laurent 2018-03-14 1:59 GMT+08:00 Laurent Dufour: > This is a port on kernel 4.16 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, this is done by introducing a rwlock > which protects the access to the mm_rb tree. Previously this was done using > SRCU but it was introducing a lot of scheduling to process the VMA's > freeing > operation which was hitting the performance by 20% as reported by Kemi Wang > [2].Using a rwlock to protect access to the mm_rb tree is limiting the > locking contention to these operations which are expected to be in a O(log > n) > order. In addition to ensure that the VMA is not freed in our back a > reference count is added and 2 services (get_vma() and put_vma()) are > introduced to handle the reference count. When a VMA is fetch from the RB > tree using get_vma() is must be later freeed using put_vma(). Furthermore, > to allow the VMA to be used again by the classic page fault handler a > service is introduced can_reuse_spf_vma(). This service is expected to be > called with the mmap_sem hold. It checked that the VMA is still matching > the specified address and is releasing its reference count as the mmap_sem > is hold it is ensure that it will not be freed in our back. In general, the > VMA's reference count could be decremented when holding the mmap_sem but it > should not be increased as holding the mmap_sem is ensuring that the VMA is > stable. I can't see anymore the overhead I got while will-it-scale > benchmark anymore. > > 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 lockings 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. > > The locking of the PTE is done with interrupts disabled, this allows to > check for the PMD to ensure that there is not an ongoing collapsing > operation. Since khugepaged is firstly set the PMD to pmd_none and then is > waiting for the other CPU to have catch the IPI interrupt, if the pmd is > valid at the time the PTE is locked, we have the guarantee that the > collapsing opertion will have to wait on the PTE lock to move foward. This > allows the SPF handler to map the PTE safely. If the PMD value is different > than the one recorded at the beginning of the SPF operation, the classic > page fault handler will be called to handle the operation while holding the > mmap_sem. As the PTE lock is done with the interrupts disabled, the lock is > done using spin_trylock() to avoid dead lock when handling a page fault > while a TLB invalidate is requested by an other CPU holding the PTE. > > Support for THP is not done because when checking for the PMD, we can be > confused by an in progress collapsing operation done by khugepaged. The > issue is that pmd_none() could be true either if the PMD is not already > populated or if the underlying PTE are in the way to be collapsed. So we > cannot safely allocate a PMD if pmd_none() is true. > > This series a new software performance event named 'speculative-faults' or > 'spf'. It counts the number of successful page fault event handled in a > speculative way. When recording 'faults,spf' events, the faults one is > counting the total number of page fault events while 'spf' is only counting > the part of the faults processed in a speculative
Re: [PATCH v9 00/24] Speculative page faults
On 14/03/2018 14:11, Michal Hocko wrote: > On Tue 13-03-18 18:59:30, Laurent Dufour wrote: >> Changes since v8: >> - Don't check PMD when locking the pte when THP is disabled >>Thanks to Daniel Jordan for reporting this. >> - Rebase on 4.16 > > Is this really worth reposting the whole pile? I mean this is at v9, > each doing little changes. It is quite tiresome to barely get to a > bookmarked version just to find out that there are 2 new versions out. I agree, I could have sent only a change for the concerned patch. But the previous series has been sent a month ago and this one is rebased on the 4.16 kernel. > I am sorry to be grumpy and I can understand some frustration it doesn't > move forward that easilly but this is a _big_ change. We should start > with a real high level review rather than doing small changes here and > there and reach v20 quickly. > > I am planning to find some time to look at it but the spare cycles are > so rare these days... I understand that this is a big change and I'll try to not post a new series until I get more feedback from this one. Thanks, Laurent.
Re: [PATCH v9 00/24] Speculative page faults
On Tue 13-03-18 18:59:30, Laurent Dufour wrote: > Changes since v8: > - Don't check PMD when locking the pte when THP is disabled >Thanks to Daniel Jordan for reporting this. > - Rebase on 4.16 Is this really worth reposting the whole pile? I mean this is at v9, each doing little changes. It is quite tiresome to barely get to a bookmarked version just to find out that there are 2 new versions out. I am sorry to be grumpy and I can understand some frustration it doesn't move forward that easilly but this is a _big_ change. We should start with a real high level review rather than doing small changes here and there and reach v20 quickly. I am planning to find some time to look at it but the spare cycles are so rare these days... -- Michal Hocko SUSE Labs
[PATCH v9 00/24] Speculative page faults
This is a port on kernel 4.16 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, this is done by introducing a rwlock which protects the access to the mm_rb tree. Previously this was done using SRCU but it was introducing a lot of scheduling to process the VMA's freeing operation which was hitting the performance by 20% as reported by Kemi Wang [2].Using a rwlock to protect access to the mm_rb tree is limiting the locking contention to these operations which are expected to be in a O(log n) order. In addition to ensure that the VMA is not freed in our back a reference count is added and 2 services (get_vma() and put_vma()) are introduced to handle the reference count. When a VMA is fetch from the RB tree using get_vma() is must be later freeed using put_vma(). Furthermore, to allow the VMA to be used again by the classic page fault handler a service is introduced can_reuse_spf_vma(). This service is expected to be called with the mmap_sem hold. It checked that the VMA is still matching the specified address and is releasing its reference count as the mmap_sem is hold it is ensure that it will not be freed in our back. In general, the VMA's reference count could be decremented when holding the mmap_sem but it should not be increased as holding the mmap_sem is ensuring that the VMA is stable. I can't see anymore the overhead I got while will-it-scale benchmark anymore. 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 lockings 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. The locking of the PTE is done with interrupts disabled, this allows to check for the PMD to ensure that there is not an ongoing collapsing operation. Since khugepaged is firstly set the PMD to pmd_none and then is waiting for the other CPU to have catch the IPI interrupt, if the pmd is valid at the time the PTE is locked, we have the guarantee that the collapsing opertion will have to wait on the PTE lock to move foward. This allows the SPF handler to map the PTE safely. If the PMD value is different than the one recorded at the beginning of the SPF operation, the classic page fault handler will be called to handle the operation while holding the mmap_sem. As the PTE lock is done with the interrupts disabled, the lock is done using spin_trylock() to avoid dead lock when handling a page fault while a TLB invalidate is requested by an other CPU holding the PTE. Support for THP is not done because when checking for the PMD, we can be confused by an in progress collapsing operation done by khugepaged. The issue is that pmd_none() could be true either if the PMD is not already populated or if the underlying PTE are in the way to be collapsed. So we cannot safely allocate a PMD if pmd_none() is true. This series a new software performance event named 'speculative-faults' or 'spf'. It counts the number of successful page fault event handled in a speculative way. When recording 'faults,spf' events, the faults one is counting the total number of page fault events while 'spf' is only counting the part of the faults processed in a speculative way. There are some trace events introduced by this series. They allow to identify why the page faults where not processed in a speculative way. This doesn't take in account the faults generated by a monothreaded process which