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: Tune reader_thread poll timeout value


> [...]
> - with high value such as 5 seconds, low throughput trace is dumped
> only every 5s. So of course, do not use probe timer.s(1) to get
> trace dumped every s on command line, you will have 5 correct infos
> in 1 shot every 5s.
>
> - no impact in performance, when trace throughput is high, ppoll()
> returns before timeout expires. [...]

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?


[FT]
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.

- FChE

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]