On 7/10/20 2:55 AM, Guoqing Jiang wrote: > Hi Ming, > > On 7/10/20 2:53 AM, Ming Lei wrote: >> Hi Guoqing, >> >> On Thu, Jul 09, 2020 at 08:48:08PM +0200, Guoqing Jiang wrote: >>> Hi Ming, >>> >>> On 7/8/20 4:06 PM, Guoqing Jiang wrote: >>>> On 7/8/20 4:02 PM, Guoqing Jiang wrote: >>>>>> Hi Guoqing, >>>>>> >>>>>> I believe it isn't hard to write a ebpf based script(bcc or >>>>>> bpftrace) to >>>>>> collect this kind of performance data, so looks not necessary to do it >>>>>> in kernel. >>>>> Hi Ming, >>>>> >>>>> Sorry, I don't know well about bcc or bpftrace, but I assume they >>>>> need to >>>>> read the latency value from somewhere inside kernel. Could you point >>>>> how can I get the latency value? Thanks in advance! >>>> Hmm, I suppose biolatency is suitable for track latency, will look into >>>> it. >>> I think biolatency can't trace data if it is not running, >> Yeah, the ebpf prog is only injected when the trace is started. >> >>> also seems no >>> place >>> inside kernel have recorded such information for ebpf to read, correct me >>> if my understanding is wrong. >> Just record the info by starting the bcc script in case you need that, is there >> anything wrong with this usage? Always doing such stuff in kernel isn't fair for >> users which don't care or need this info. > > That is why we add a Kconfig option and set it to N by default. And I > suppose > with modern cpu, the cost with several more instructions would not be that > expensive even the option is enabled, just my $0.02. Never justify it with a Kconfig option, that doesn't help anything at all. Distros then enable it, and all users are stuck with this overhead. The ktime_get() is definitely extra overhead. FWIW, I agree with Ming here in that this can easily be done from userspace. And if that's the case, then I don't see why everybody should carry this extra burden. -- Jens Axboe
