From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Subject: Re: [PATCH 2/2] tracing/core: use appropriate waiting on trace_pipe
Date: Tue, 10 Feb 2009 15:54:49 +0100 [thread overview]
Message-ID: <20090210145449.GF5836@nowhere> (raw)
In-Reply-To: <20090210120205.GA19297@elte.hu>
On Tue, Feb 10, 2009 at 01:02:05PM +0100, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > static int tracing_wait_pipe(struct file *filp)
> > {
> > + DEFINE_WAIT(wait);
> > struct trace_iterator *iter = filp->private_data;
> >
> > while (trace_empty(iter)) {
> > -
> > if ((filp->f_flags & O_NONBLOCK)) {
> > return -EAGAIN;
> > }
> >
> > - /*
> > - * This is a make-shift waitqueue. The reason we don't use
> > - * an actual wait queue is because:
> > - * 1) we only ever have one waiter
> > - * 2) the tracing, traces all functions, we don't want
> > - * the overhead of calling wake_up and friends
> > - * (and tracing them too)
> > - * Anyway, this is really very primitive wakeup.
> > - */
> > - set_current_state(TASK_INTERRUPTIBLE);
> > - iter->tr->waiter = current;
> > -
> > mutex_unlock(&trace_types_lock);
> >
> > - /* sleep for 100 msecs, and try again. */
> > - schedule_timeout(HZ/10);
> > + if (might_hold_runqueue_lock(iter->trace)) {
> > + /*
> > + * This is a make-shift waitqueue. The reason we don't
> > + * use an actual wait queue is because:
> > + * 1) we only ever have one waiter
> > + * 2) the tracing, traces all functions, we don't want
> > + * the overhead of calling wake_up and friends
> > + * (and tracing them too)
> > + * Anyway, this is really very primitive wakeup.
> > + */
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(HZ / 10);
>
> Instead of adding this ugly dynamic switch in the middle of tracing_wait_pipe(), i'd
> suggest to restructure this along the following lines:
>
> 1) move the new waiting waitqueue based function into default_wait_pipe() function
>
> 2) add a poll_wait_pipe() function as well that does the old 100 msecs polling
> method
>
> 3) add a iter->wait_pipe() method that is called by tracing_wait_pipe()
>
> 4) make register_tracer() fill in default_wait_pipe() for plugins that do not
> register an explicit ->wait_pipe method.
>
> That way the 'special', intrusive tracers (like sched and function tracer) can still
> specify poll_wait_pipe() - while the others will default to the waitqueue based
> tracing_wait_pipe() method.
>
> Ingo
That's more smart indeed!
I will take advantage of this v2 to add more comments on the struct tracer.
Thanks.
prev parent reply other threads:[~2009-02-10 14:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 3:47 [PATCH 2/2] tracing/core: use appropriate waiting on trace_pipe Frederic Weisbecker
2009-02-10 12:02 ` Ingo Molnar
2009-02-10 14:54 ` 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=20090210145449.GF5836@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox