On 25/06/20(Thu) 23:45, Yuichiro NAITO wrote: > From: Martin Pieuchot <[email protected]> > Subject: Re: make btrace interval event to reciprocal of ticks > Date: Thu, 25 Jun 2020 11:36:48 +0200 > > > On 23/06/20(Tue) 12:04, Yuichiro NAITO wrote: > >> Current btrace has `interval:hz:1` probe that makes periodically events. > >> `interval:hz:1` looks to make events once per second (= 1Hz), > >> but current implementation makes once per tick (= 100Hz on amd64). > >> I think the interval should be counted by reciprocal of ticks so that fit > >> to Hz. > > > > Indeed the current implementations assumes it's a number of ticks. How > > does other tracing tool behave? Is the behavior you suggest similar to > > bpftrace(8) or dtrace(1)? > > I don't know about bpftrace(8). > Dtrace has interval timer in Hz as Lauri says.
Seems to be the same, so I'll commit your diff. > > Would it be complicated to add support for other units, like 'ms' or > > 'sec'? In that case 'profile:s:10' would mean every 10sec while > > 'profile:hz:10' would mean every ~6sec, right? > > I feel it's ok to just rename 'interval:hz' to 'interval:ticks' with > no implementation change. (but I hope that 100 is allowed.) > We can know the tick interval from 'hz' in `sysctl -n kern.clockrate`. > So it's easy to understand that 'interval:ticks:N' fires on every N ticks. > > And tick resolution is not so high. > In my patch, 51 Hz ~ 100 Hz is calculated to 10 ms (=1 tick) interval. > It might confuse some users. > > In my usecase, I want 10ms ~ 1sec intervals. > If N is allowed over 99, 'interval:ticks:N' can be useful to me. Well ideally we should be able to specify an interval in second or millisecond. If you or somebody else wants to implement that, I suppose it makes sense now to change `dtrq_rate' to be a uint64_t and encode the interval in nanosecond.
