From: bob <bob@watson.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: bob <bob@watson.ibm.com>, Karim Yaghmour <karim@opersys.com>,
<okrieg@us.ibm.com>, <trz@us.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
LTT-Dev <ltt-dev@shafik.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [ltt-dev] Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure
Date: Sun, 22 Sep 2002 20:07:26 -0400 (EDT) [thread overview]
Message-ID: <15758.22318.507460.859271@k42.watson.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0209230108001.3792-100000@localhost.localdomain>
Yes this is simple code - similar to the model we use in K42. Still,
couple of things about the below.
1) the !event_wanted can be done outside the function, in a macro so that
the only cost if tracing is disabled is a hot cache hit on a mask (not
function call) - that helps with your comment:
> The event_wanted() filter function should be made as fast as possible.
2) If you use the lockless scheme you do not need to disable interrupts.
In K42 we manage to do the entire log operation in 21 instructions and
about as many cycles (couple more for getting time). We do this from user
space as well, disabling interrupts precludes this model (may of may not be
a problem). I was really leaning hard away from even the cost of making a
system call and disabling interrupts. Do people on the kernel dev team
feel this is an acceptable cost? Is migration prevented when interrupts
are disabled? This is something for us to consider.
3) All trace events should not have to have the same number of data words
logged - though I think that's just a packaging/interface issue the code
below would just be placed behind macros which correctly package up the
right number of arguments.
Ingo Molnar writes:
>
> this is that a trace point should do, at most:
>
> --------------------->
> task_t *tracer_task;
>
> int curr_idx[NR_CPUS];
> int curr_pending[NR_CPUS];
>
> struct trace_event **trace_ring;
>
> void trace(event, data1, data2, data3)
> {
> int cpu = smp_processor_id();
> int idx, pending, *curr = curr_idx + cpu;
> struct trace_event *t;
> unsigned long flags;
>
> if (!event_wanted(current, event, data1, data2, data3))
> return;
>
> local_irq_save(flags);
>
> idx = ++curr_idx[cpu] & (NR_TRACE_ENTRIES - 1);
> pending = ++curr_pending[cpu];
>
> t = trace_ring[cpu] + idx;
>
> t->event = event;
> rdtscll(t->timestamp);
> t->data1 = data1;
> t->data2 = data2;
> t->data3 = data3;
>
> if (curr_pending == TRACE_LOW_WATERMARK && tracer_task)
> wake_up_process(tracer_task);
>
> local_irq_restore(flags);
> }
>
> this should cover most of what's needed. The event_wanted() filter
> function should be made as fast as possible. Note that the irq-disabled
> section is not strictly needed but nice and also makes it work on the
> preemptible kernel. (It's not a big issue at all to run these few
> instructions with irqs disabled.)
>
> [there are also other details like putting curr_index and curr_pending
> into the per-cpu area and similar stuff.]
>
> Ingo
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@listserv.shafik.org
> http://www.listserv.shafik.org/listserv/listinfo/ltt-dev
next prev parent reply other threads:[~2002-09-23 0:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-22 5:43 Karim Yaghmour
2002-09-22 10:42 ` Ingo Molnar
2002-09-22 10:50 ` Ingo Molnar
2002-09-22 17:26 ` Roman Zippel
2002-09-22 18:35 ` Linus Torvalds
2002-09-22 19:18 ` Karim Yaghmour
2002-09-22 19:40 ` Ingo Molnar
2002-09-22 22:09 ` Karim Yaghmour
2002-09-22 22:24 ` Ingo Molnar
2002-09-22 22:41 ` Karim Yaghmour
2002-09-22 22:59 ` Ingo Molnar
2002-09-22 22:50 ` Ingo Molnar
2002-09-22 23:32 ` Karim Yaghmour
2002-09-23 7:41 ` Ingo Molnar
2002-09-23 15:12 ` Karim Yaghmour
2002-09-23 20:11 ` Andreas Ferber
2002-09-23 23:31 ` Karim Yaghmour
2002-09-22 21:29 ` [ltt-dev] " bob
2002-09-22 19:06 ` Karim Yaghmour
2002-09-22 19:33 ` Karim Yaghmour
2002-09-22 21:20 ` [ltt-dev] " bob
2002-09-22 21:39 ` Ingo Molnar
2002-09-22 22:37 ` bob
2002-09-22 22:55 ` Ingo Molnar
2002-09-22 22:52 ` bob
2002-09-22 23:02 ` Ingo Molnar
2002-09-22 23:03 ` bob
2002-09-22 23:19 ` Ingo Molnar
2002-09-22 23:50 ` bob
2002-09-22 23:32 ` Ingo Molnar
2002-09-23 0:07 ` bob [this message]
2002-09-23 7:27 ` Ingo Molnar
2002-09-23 13:59 ` bob
2002-09-23 0:08 ` Karim Yaghmour
2002-09-22 22:58 ` Karim Yaghmour
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=15758.22318.507460.859271@k42.watson.ibm.com \
--to=bob@watson.ibm.com \
--cc=karim@opersys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=mingo@elte.hu \
--cc=okrieg@us.ibm.com \
--cc=torvalds@transmeta.com \
--cc=trz@us.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
all inboxes | Powered by JetHome®