This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: PR 6504
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 16 May 2008 13:01:35 -0400
- Subject: Re: PR 6504
- References: <482C8404.6080308@redhat.com> <mailman.4430.1210880070.3267.external-perftools-list@redhat.com> <y0m3aoih4qy.fsf_-_@ton.toronto.redhat.com>
Hi Frank,
Thank you for your comment.
Frank Ch. Eigler wrote:
> Masami Hiramatsu <mhiramat@redhat.com> writes:
>
>> [...] Actually, relay_switch_subbuf() doesn't call any kernel
>> functions except __mod_timer (others are primitive inlines or
>> macros). so, with current patch which is for systemtap runtime, you
>> don't need to update the blacklist.
>
> That's good. The patch attached to bug #6504 looks plausible - I'm
> not a utt/runtime expert - but I'm worried by a few things. It seems
> like there are several possible races (utt->wakeup being set/cleared;
> _utt_wakeup_readers:waitqueue_active vs. wake_up_interruptible), and
Sure, I think that doesn't cause races.
utt->wakeup is set to be 1 right after changing buf->produced in
utt_switch_subbuf. utt_wakeup_timer reads it, and then, clears
it if it is 1.
For example, utt_switch_subbuf sets utt->wakeup = 1 right after
utt_wakeup_timer read it. if utt->wakeup=0 when reading, it isn't
cleared(so, it will be treated next time). if utt->wakeup=1 when
reading, it is cleared, and the timer tries to wake readers up.
Actually, there is a case that the timer do nothing when utt->wakeup
is set 1 just after cleared. but it does not cause any problem like as
process-sleeping-forever.
And I also think it is not a problem that waitqueue_active vs.
wake_up_interruptible, because only utt_wakeup_timer(system global timer)
and signals wake the readers up.
> the UTT_TIMER_INTERVAL seems too small as an unconditional poll. (I
> wonder the same thing about STP_WORK_TIMER in
> runtime/transport/transport.c.)
Indeed, it should be discussed how long/short interval is enough for
systemtap, or we'd better to make an adaptive-interval timer which adjusts
interval depending on the frequency of work.
>
> To what extent could a delayed-work backend simplify this code? (If
> that subsystem needs to be blacklisted, so be it.)
I think we can't use it, the delayed-work also uses timers:-(
>
> - FChE
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com