qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Prerna Saxena <prerna@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Maneesh Soni <maneesh@linux.vnet.ibm.com>,
	Ananth <ananth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Toggle tracepoint state
Date: Fri, 18 Jun 2010 13:46:25 +0100	[thread overview]
Message-ID: <AANLkTikve3BE_atcV4E-xaphAMuhK_j7M-S_gpH-DVc9@mail.gmail.com> (raw)
In-Reply-To: <4C1B6573.5050705@linux.vnet.ibm.com>

On Fri, Jun 18, 2010 at 1:24 PM, Prerna Saxena
<prerna@linux.vnet.ibm.com> wrote:
> On 06/17/2010 09:33 PM, Stefan Hajnoczi wrote:
>>> +}
>>> +
>>> +static Tracepoint* find_tracepoint_by_name(const char *tname)
>>> +{
>>> +    unsigned int i, name_hash;
>>> +
>>> +    if (!tname) {
>>> +        return NULL;
>>> +    }
>>> +
>>> +    name_hash = qemu_hash(tname);
>>> +
>>> +    for (i=0; i<NR_TRACEPOINTS; i++) {
>>> +        if (trace_list[i].hash == name_hash&&
>>> +                       !strncmp(trace_list[i].tp_name, tname,
>>> strlen(tname))) {
>>> +            return&trace_list[i];
>>> +        }
>>> +    }
>>> +    return NULL; /* indicates end of list reached without a match */
>>
>> I don't see the need for hashing.  We don't actually have a hash table
>> and are doing a linear search.  There will be a smallish constant number
>> of trace events and only change_tracepoint_by_name() needs to do a
>> lookup.  There's no need to optimize that.
>>
>
> I was only optimising lookups. Instead of doing a strlen()-size comparison
> for each tracepoint, we end up doing a constant int-size comparison till
> there is possibility of hash collision. Strlen()-size lookups isnt really an
> issure right now, but will be more glaring if qemu ends up having a much
> larger number of tracepoints.

The thing is we only need to do lookups when tracepoints are
enabled/disabled.  That is a very rare operation, not critical path.

This feels like premature optimization.  If there is a performance
bottleneck down the road we can switch to a data structure that has
better time complexity than an array.  This is an easy change to make
later because it will not affect the user interface.

In the meantime linear strcmp() over an array keeps the code simple.
We can drop the tdb_hash() patch and remove some lines from this
patch.

>>> diff --git a/tracetool b/tracetool
>>> index 2c73bab..00af205 100755
>>> --- a/tracetool
>>> +++ b/tracetool
>>> @@ -123,14 +123,20 @@ linetoc_end_nop()
>>>  linetoh_begin_simple()
>>>  {
>>>      cat<<EOF
>>> +#include<stdbool.h>
>>> +
>>>  typedef unsigned int TraceEvent;
>>>
>>> +void init_tracepoint_table(void);
>>> +void init_tracepoint(const char *tname, TraceEvent tevent);
>>>  void trace1(TraceEvent event, unsigned long x1);
>>>  void trace2(TraceEvent event, unsigned long x1, unsigned long x2);
>>>  void trace3(TraceEvent event, unsigned long x1, unsigned long x2,
>>> unsigned long x3);
>>>  void trace4(TraceEvent event, unsigned long x1, unsigned long x2,
>>> unsigned long x3, unsigned long x4);
>>>  void trace5(TraceEvent event, unsigned long x1, unsigned long x2,
>>> unsigned long x3, unsigned long x4, unsigned long x5);
>>>  void do_info_trace(Monitor *mon);
>>> +void do_info_all_tracepoints(Monitor *mon);
>>> +void change_tracepoint_state(const char *tname, bool tstate);
>>>  EOF
>>>
>>>      simple_event_num=0
>>> @@ -163,22 +169,38 @@ EOF
>>>
>>>  linetoh_end_simple()
>>>  {
>>> -    return
>>> +    cat<<EOF
>>> +#define NR_TRACEPOINTS $simple_event_num
>>> +EOF
>>>  }
>>>
>>>  linetoc_begin_simple()
>>>  {
>>> -    return
>>> +    cat<<EOF
>>> +#include "trace.h"
>>> +
>>> +void init_tracepoint_table(void) {
>>> +EOF
>>
>> Have you looked at module.h?  Perhaps that provides a good solution for
>> initializing trace events.  It would allow the vl.c changes to be done
>> without an #ifdef.
>
> Thanks for the tip, I'll check.

I also wonder if it's possible to statically initialize the TraceEvent
array in the generated trace.c.  That way we need no vl.c startup
magic and tracing is available even in the very early stages of QEMU
startup.  What do you think?

Stefan

  reply	other threads:[~2010-06-18 12:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 12:35 [Qemu-devel] [PATCH 0/3] Monitor support QEMU trace framework Prerna Saxena
2010-06-16 12:40 ` [Qemu-devel] [PATCH 1/3] Export hash function Prerna Saxena
2010-06-16 12:42 ` [Qemu-devel] [PATCH 2/3] Monitor command 'info trace' Prerna Saxena
2010-06-17 15:08   ` [Qemu-devel] " Stefan Hajnoczi
2010-06-18 11:58     ` Prerna Saxena
2010-06-18 12:34       ` Stefan Hajnoczi
2010-06-16 12:44 ` [Qemu-devel] [PATCH 3/3] Toggle tracepoint state Prerna Saxena
2010-06-17 16:03   ` [Qemu-devel] " Stefan Hajnoczi
2010-06-18 12:24     ` Prerna Saxena
2010-06-18 12:46       ` Stefan Hajnoczi [this message]
2010-06-16 13:50 ` [Qemu-devel] Re: [PATCH 0/3] Monitor support QEMU trace framework Jan Kiszka

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=AANLkTikve3BE_atcV4E-xaphAMuhK_j7M-S_gpH-DVc9@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=aliguori@us.ibm.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=maneesh@linux.vnet.ibm.com \
    --cc=prerna@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).