Re: [PATCH v10 00/25] Speculative page faults

On 02/05/2018 16:17, Punit Agrawal wrote: > Hi Laurent, > > One query below - > > Laurent Dufour 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

Re: [PATCH v10 00/25] Speculative page faults

On 02/05/2018 16:17, Punit Agrawal wrote: > Hi Laurent, > > One query below - > > Laurent Dufour 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

Re: [PATCH v10 00/25] Speculative page faults

Hi Laurent, One query below - Laurent Dufour 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

Re: [PATCH v10 00/25] Speculative page faults

Hi Laurent, One query below - Laurent Dufour 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

[PATCH v10 00/25] 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

[PATCH v10 00/25] 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