From: Frederic Weisbecker <fweisbec@gmail.com>
To: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH][RFC] perf lock: Distribute numerical IDs for each lock instances
Date: Wed, 16 Dec 2009 20:41:20 +0100 [thread overview]
Message-ID: <20091216194117.GD5211@nowhere> (raw)
In-Reply-To: <a6b9f31a0912140644t50c8aa9y7b6c51339374bb94@mail.gmail.com>
On Mon, Dec 14, 2009 at 11:44:53PM +0900, Hitoshi Mitake wrote:
> On Mon, Dec 14, 2009 at 22:30, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > So if I understand well, this maps each lockdep_map
> > into a unique index, right?
>
> There's a slightly difference. This patch maps each lock instances
> (spinlock_t, rwlock_t, etc) into a unique index.
Yeah.
> The usecase I assumed is (for example) that
> dividing copying name of lock instances to userspace from lock trace events.
>
> I think that copying name of lock at every trace event time is not efficient.
> For example, ID <-> name table can be made in my way.
> So each lock events only have to output it's ID.
> Then, perf lock reads the table from file on debugfs.
> Finally perf lock can refer the table and obtain name of each lock.
> This may reduce the data transfer between kernel and userspace.
>
> But... you are right. This effect can be also obtained by hashlist.
> There's no requirement of implementing array.
> And optimization should be done after implementation.
> I'll back to coding of perf lock, sorry..
>
> # But I think that this is useful to measure the overhead of hashlist! :)
>
Ah I understand better. Indeed if we have such index:lock_name mapping
available from debugfs, the tracing path would be more efficient because
we'd only need to trace the index, no need to copy the name.
Actually that looks like a good idea.
prev parent reply other threads:[~2009-12-16 19:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-13 8:02 [PATCH][RFC] perf lock: Distribute numerical IDs for each lock instances Hitoshi Mitake
2009-12-14 13:30 ` Frederic Weisbecker
2009-12-14 14:44 ` Hitoshi Mitake
2009-12-16 19:41 ` Frederic Weisbecker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091216194117.GD5211@nowhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.