Re: uvm_map_inentry diff for testing

2020-03-18 Thread Martin Pieuchot
On 18/03/20(Wed) 11:55, Mark Kettenis wrote: > > Date: Wed, 18 Mar 2020 11:34:59 +0100 > > From: Martin Pieuchot > > > > On 17/03/20(Tue) 20:08, Mark Kettenis wrote: > > > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64 > > > machine, I noticed that the kernel was spending a

Re: uvm_map_inentry diff for testing

2020-03-18 Thread Mark Kettenis
> Date: Wed, 18 Mar 2020 11:34:59 +0100 > From: Martin Pieuchot > > On 17/03/20(Tue) 20:08, Mark Kettenis wrote: > > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64 > > machine, I noticed that the kernel was spending a lot of time (6.84%) > > in uvm_map_inentry(). This is

Re: uvm_map_inentry diff for testing

2020-03-18 Thread Martin Pieuchot
On 17/03/20(Tue) 20:08, Mark Kettenis wrote: > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64 > machine, I noticed that the kernel was spending a lot of time (6.84%) > in uvm_map_inentry(). This is caused by kernel lock contention. > Pushing baack the kernel lock further into

uvm_map_inentry diff for testing

2020-03-17 Thread Mark Kettenis
While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64 machine, I noticed that the kernel was spending a lot of time (6.84%) in uvm_map_inentry(). This is caused by kernel lock contention. Pushing baack the kernel lock further into the slow path reduces the time to 0.05%. Now mpi@