This is the mail archive of the 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: Tune reader_thread poll timeout value

>I'm missing something.  Why does the second item not moot the first?
>IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports
>wake up the ppoll() to avoid waiting till 5s?
>ppoll() wakes-up only when 1 buffer is full. timer.s(1) wakes-up whatever kernel thread (by the way, I
>should check that with contextswitch trace) but trace throughput is very low. After 5 seconds, ppoll
>time-outs and the 5 traces done by timer.s(1) at every second are dumped.
>When I say "do not use", it is really for interactivity with terminal. People may want to get some
>small metric every s, but 5 metrics will be displayed every 5s. Of course, for a log read later, you
>don't care.
>So, yes, people should be cautious with this but well, this is for embedded platforms and this is
>really our goal.

Does it make sense then ? In case of low throughput use cases, we have been for a long time dumping buffers only every few s isntead of 200us at the cost of printing latency. Rare cases but needed.


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

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