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 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.