Hi Yafang,
I've felt a bit stuck on this, as tracepoints alone don't quite
address my use case (performance overhead is too high), but I haven't
been able to come up with a palatable approach which does. I was
planning to conduct an experiment on Google production servers, to
provide real-world
On Fri, Jun 19, 2020 at 6:43 AM Axel Rasmussen wrote:
>
> The goal is to be able to collect a latency histogram for contended
> mmap_lock acquisitions. This will be used to diagnose slowness observed
> in production workloads, as well as to measure the effect of upcoming
> mmap_lock optimizations
Peter, one additional question for you.
Would you accept this patch if:
- The rwsem.{h,c} and lockdep.h changes were reverted
- It was split up into 2-3 commits
?
Thanks!
On Fri, Jun 19, 2020 at 9:28 AM Axel Rasmussen wrote:
>
> On Fri, Jun 19, 2020 at 1:30 AM Peter Zijlstra wrote:
> >
> > On
On Fri, Jun 19, 2020 at 1:30 AM Peter Zijlstra wrote:
>
> On Thu, Jun 18, 2020 at 03:22:25PM -0700, Axel Rasmussen wrote:
> > diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> > index f11b9bd3431d..6aabea1cbc5d 100644
> > --- a/kernel/locking/rwsem.c
> > +++ b/kernel/locking/rwsem.c
On Thu, Jun 18, 2020 at 03:22:25PM -0700, Axel Rasmussen wrote:
> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> index f11b9bd3431d..6aabea1cbc5d 100644
> --- a/kernel/locking/rwsem.c
> +++ b/kernel/locking/rwsem.c
> @@ -1495,6 +1495,20 @@ void __sched down_read(struct rw_semaphore
On Thu, Jun 18, 2020 at 03:22:25PM -0700, Axel Rasmussen wrote:
>
> include/linux/lockdep.h | 47 ++
> include/linux/mmap_lock.h| 27 ++-
> include/linux/rwsem.h| 12 ++
> include/trace/events/mmap_lock.h | 76 +
> kernel/locking/rwsem.c |
The goal is to be able to collect a latency histogram for contended
mmap_lock acquisitions. This will be used to diagnose slowness observed
in production workloads, as well as to measure the effect of upcoming
mmap_lock optimizations like maple trees and range-based locks. The
"start_locking" and
7 matches
Mail list logo
