From: Waiman Long <waiman.long@hp.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Scott J Norton <scott.norton@hp.com>,
Douglas Hatch <doug.hatch@hp.com>,
Don Zickus <dzickus@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH v3 1/2] perf tool: improves DSO long names search speed with RB tree
Date: Wed, 24 Sep 2014 11:29:07 -0400 [thread overview]
Message-ID: <5422E343.6090605@hp.com> (raw)
In-Reply-To: <20140918151057.GG2770@kernel.org>
On 09/18/2014 11:10 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 18, 2014 at 09:30:20AM -0400, Waiman Long escreveu:
>> +++ b/tools/perf/util/dso.c
>> @@ -651,6 +651,80 @@ struct dso *dso__kernel_findnew(struct machine *machine, const char *name,
>> return dso;
>
>> +/*
>> + * RB root of DSOs sorted by the long name
>> + */
>> +struct rb_root dso__root = { NULL };
> Why do we still have a global variable for this? I thought that we would
> be having this in struct machine?
>
> Ok, I shouldn't have done this, but I went on and looked at the second
> patch, and there, this goes away, why not avoid introducing the global
> in the first place?
The global variable was added to make the first patch compilable by
itself. I will take this out in the next version of the patch.
> I.e. the existing code operates on a data structure that holds struct
> dsos, you are switching to a new data structure, so it looked natural to
> me to do this in one step, no?
Yes, I think that makes sense.
> Also at some point I thought about adding rb_tree helper functions to do
> some rb__for_each() like operation, i.e. to sequentially access the
> rb_tree instead of using it for searching using its key. PeterZ
> rightfully nacked that because that would, IIRC, encourage people to use
> a rb_tree to do linear searches for normal operation, i.e. not just for
> rb_tree__printf() dump like routines:
>
> https://lkml.org/lkml/2010/1/13/227
>
> Also I saw at least one place where some foo__for_each_entry_safe() is
> used but the loop doesn't look like it will remove/add anything to the
> data structure that is being made "_safe", i.e. it should remain
> foo__for_each_entry(), as it was before.
>
> So, I would _keep_ the list_head, or else replace it with a another
> rb_node to do lookups on it by shortname the same way we do for long
> names.
>
> The cheapest thing now would be for solving your problem, i.e. use a
> rb_tree for searching for long names, keep the list_head for short names
> linear searches.
>
> I suggest having a
>
> struct dsos {
> struct list_head short_names;
> struct rb_root long_names;
> };
>
> Then make struct machine use this type for:
>
> struct dsos kernel_dsos, user_dsos;
>
> Then all those dsos__find* routines stop receiving a list_head pointer
> and start receiving a "struct dsos" instance.
>
> That way it can add the dso to both containers, the one "sorted" by
> short names (that linear search, just like before) and to the rb_tree
> sorted by long names.
>
> - Arnaldo
I think this is a good idea. I will incorporate that in my next patch.
BTW, the list isn't sorted in any way. So I won't use the same structure
field names as you have suggested.
-Longman
next prev parent reply other threads:[~2014-09-24 15:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 13:30 [PATCH v3 0/2] perf tool: improves DSO long names search speed with RB tree Waiman Long
2014-09-18 13:30 ` [PATCH v3 1/2] " Waiman Long
2014-09-18 15:10 ` Arnaldo Carvalho de Melo
2014-09-24 15:29 ` Waiman Long [this message]
2014-09-18 13:30 ` [PATCH v3 2/2] perf tool: iterate DSOs with rbtree instead of list Waiman Long
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=5422E343.6090605@hp.com \
--to=waiman.long@hp.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=doug.hatch@hp.com \
--cc=dzickus@redhat.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=scott.norton@hp.com \
/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.