On 10/6/23 13:44, Alexey Kuznetsov wrote: > trace_printk() is a function which is not desired in release kernels, > if is referenced from a module, even if it is not actually used, it allocates > lots of memory and scares people with some messages. > > What can we do?
Why not switch to ftrace events? Do you mean it is not better than trace_printk? > 1. Surround it with ifdef turned off in release kernels > No. We need this at customer's environments to investigate actual problems, > modules cannot be replaced with debugging when they are in use. > 2. Just delete it. > Instead we could use systemtap to attach to running module to get desired > traces. > This facility is used frequently in any case. Contra: systemtap puts > heavy overhead, it is not easy to install, frequently customers are heavily > firewalled and do not allow debugging software to pollute their systems. > One day, when bpftrace becomes mature it could be an option. Right now > it is still useless. > 3. Convert them to userspace logging FUSE_KTRACE at higher loglevel. > Too expensive. We do not need this garbage in user space logs and it is > not easy, > userpace logging requires context pointer which is diffficult or > impossible to fetch. > > So, the third variant is suggested. It is some compromise, we preserve > debugging in code, but split actual uses of trace_printk to separate module, > which can be loaded when we need tracing. It is more expensive, includes > an indirect call and does not allow inline calls, but yet it still looks > better > than any other way. Also, a few TRACE which have analogs in userspace were > missed, convert them to FUSE_KTRACE now. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
