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
> 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
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
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@