Message ID | 1523975611-15978-1-git-send-email-ldufour@linux.vnet.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | Speculative page faults | expand |
Hi Laurent, One query below - Laurent Dufour <ldufour@linux.vnet.ibm.com> writes: [...] > > 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. The > number is the record processes per second, the higher is the best. > > BASE SPF delta > 16 CPUs x86 VM 12405.52 91104.52 634.39% > 80 CPUs P8 node 37880.01 76201.05 101.16% How do you measure the number of records processed? Is there a specific version of ebizzy that reports this? I couldn't find a way to get this information with the ebizzy that's included in ltp. > > Here are the performance counter read during a run on a 16 CPUs x86 VM: > Performance counter stats for './ebizzy -mRTp': > 860074 faults > 856866 spf > 285 pagefault:spf_pte_lock > 1506 pagefault:spf_vma_changed > 0 pagefault:spf_vma_noanon > 73 pagefault:spf_vma_notsup > 0 pagefault:spf_vma_access > 0 pagefault:spf_pmd_changed > > And the ones captured during a run on a 80 CPUs Power node: > Performance counter stats for './ebizzy -mRTp': > 722695 faults > 699402 spf > 16048 pagefault:spf_pte_lock > 6838 pagefault:spf_vma_changed > 0 pagefault:spf_vma_noanon > 277 pagefault:spf_vma_notsup > 0 pagefault:spf_vma_access > 0 pagefault:spf_pmd_changed > > In ebizzy's case most of the page fault were handled in a speculative way, > leading the ebizzy performance boost. A trial run showed increased fault handling when SPF is enabled on an 8-core ARM64 system running 4.17-rc3. I am using a port of your x86 patch to enable spf on arm64. SPF --- Performance counter stats for './ebizzy -vvvmTRp': 1,322,736 faults 1,299,241 software/config=11/ 10.005348034 seconds time elapsed No SPF ----- Performance counter stats for './ebizzy -vvvmTRp': 708,916 faults 0 software/config=11/ 10.005807432 seconds time elapsed Thanks, Punit [...]
On 02/05/2018 16:17, Punit Agrawal wrote: > Hi Laurent, > > One query below - > > Laurent Dufour <ldufour@linux.vnet.ibm.com> writes: > > [...] > >> >> 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. The >> number is the record processes per second, the higher is the best. >> >> BASE SPF delta >> 16 CPUs x86 VM 12405.52 91104.52 634.39% >> 80 CPUs P8 node 37880.01 76201.05 101.16% > > How do you measure the number of records processed? Is there a specific > version of ebizzy that reports this? I couldn't find a way to get this > information with the ebizzy that's included in ltp. I'm using the original one : http://ebizzy.sourceforge.net/ > >> >> Here are the performance counter read during a run on a 16 CPUs x86 VM: >> Performance counter stats for './ebizzy -mRTp': >> 860074 faults >> 856866 spf >> 285 pagefault:spf_pte_lock >> 1506 pagefault:spf_vma_changed >> 0 pagefault:spf_vma_noanon >> 73 pagefault:spf_vma_notsup >> 0 pagefault:spf_vma_access >> 0 pagefault:spf_pmd_changed >> >> And the ones captured during a run on a 80 CPUs Power node: >> Performance counter stats for './ebizzy -mRTp': >> 722695 faults >> 699402 spf >> 16048 pagefault:spf_pte_lock >> 6838 pagefault:spf_vma_changed >> 0 pagefault:spf_vma_noanon >> 277 pagefault:spf_vma_notsup >> 0 pagefault:spf_vma_access >> 0 pagefault:spf_pmd_changed >> >> In ebizzy's case most of the page fault were handled in a speculative way, >> leading the ebizzy performance boost. > > A trial run showed increased fault handling when SPF is enabled on an > 8-core ARM64 system running 4.17-rc3. I am using a port of your x86 > patch to enable spf on arm64. > > SPF > --- > > Performance counter stats for './ebizzy -vvvmTRp': > > 1,322,736 faults > 1,299,241 software/config=11/ > > 10.005348034 seconds time elapsed > > No SPF > ----- > > Performance counter stats for './ebizzy -vvvmTRp': > > 708,916 faults > 0 software/config=11/ > > 10.005807432 seconds time elapsed Thanks for sharing these good numbers ! > Thanks, > Punit > > [...] >
Hi Laurent, Thanks for your reply. Laurent Dufour <ldufour@linux.vnet.ibm.com> writes: > On 02/05/2018 16:17, Punit Agrawal wrote: >> Hi Laurent, >> >> One query below - >> >> Laurent Dufour <ldufour@linux.vnet.ibm.com> writes: >> >> [...] >> >>> >>> 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. The >>> number is the record processes per second, the higher is the best. >>> >>> BASE SPF delta >>> 16 CPUs x86 VM 12405.52 91104.52 634.39% >>> 80 CPUs P8 node 37880.01 76201.05 101.16% >> >> How do you measure the number of records processed? Is there a specific >> version of ebizzy that reports this? I couldn't find a way to get this >> information with the ebizzy that's included in ltp. > > I'm using the original one : http://ebizzy.sourceforge.net/ Turns out I missed the records processed in the verbose output enabled by "-vvv". Sorry for the noise. [...] >> >> A trial run showed increased fault handling when SPF is enabled on an >> 8-core ARM64 system running 4.17-rc3. I am using a port of your x86 >> patch to enable spf on arm64. >> >> SPF >> --- >> >> Performance counter stats for './ebizzy -vvvmTRp': >> >> 1,322,736 faults >> 1,299,241 software/config=11/ >> >> 10.005348034 seconds time elapsed >> >> No SPF >> ----- >> >> Performance counter stats for './ebizzy -vvvmTRp': >> >> 708,916 faults >> 0 software/config=11/ >> >> 10.005807432 seconds time elapsed > > Thanks for sharing these good numbers ! A quick run showed 71041 (no-spf) vs 122306 (spf) records/s (~72% improvement). I'd like to do some runs on a slightly larger system (if I can get my hands on one) to see how the patches behave. I'll also have a closer look at your series - the previous comments were just somethings I observed as part of trying the functionality on arm64. Thanks, Punit