This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 6504


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]