OK, I made TRACEME() (only used in one place), to be calling trace_printk(), which in turns feeds into the /prof/kptrace. The trace_printk() has been enhanced to emit a backtrace as well. Same branch.
On Thu, Nov 5, 2015 at 11:22 AM, Davide Libenzi <[email protected]> wrote: > There is only one call to TRACEME(), in kthread.c. > IMO mixing time-based sampling, with call based, has not much sense. > Maybe the TRACEME could generate data for kprof_write_sysrecord(), which > is a different data stream, which is isolated from the time based sampling > (kind of dmesg). > > > On Thu, Nov 5, 2015 at 11:13 AM, Davide Libenzi <[email protected]> > wrote: > >> Currently "start" starts the timers in all CPUs, and start profling. >> Stop does the contrary. >> Profile data is no more "volatile" and you can use "cp" instead of baing >> forced to use "cat", which was kind of weird. >> The cost of profiling is not only RAM. >> With hooks now in MM and process creation, there is a little cost there >> as well. >> >> >> >> On Thu, Nov 5, 2015 at 11:07 AM, Barret Rhoden <[email protected]> >> wrote: >> >>> On 2015-10-31 at 10:06 "'Davide Libenzi' via Akaros" >>> <[email protected]> wrote: >>> > Moreover, I think the kprofinit is called at boot time, which >>> > allocates and sets up the profiler, even though nobody is using it. >>> > IMO the profiler should have zero cost if nobody is using it, and the >>> > setup should be done once the first user attaches, and be undone >>> > after the last detaches. >>> >>> One thing is that the only cost to kprofinit() is RAM. Tracking the >>> attach/detach is a bit more painful, but if you want to do it, then go >>> for it. It'll also require being more careful about removing the >>> per-cpu buffers (need to make sure there are no samples in progress >>> across the entire machine in a race-free manner). You also need to >>> know when the last user detaches (there is no 'detach' command). The >>> hassle didn't seem worth the RAM. >>> >>> Another alternative would be to only do the init stuff the first time >>> attach is called (use the run_once() macro). That way the RAM usage of >>> init() is only taken on attach, but we don't need to deal with removing >>> it. >>> >>> As far as other cleanup goes, there's other stuff in there that might >>> be deletable. Anything related to Kprofdataqid can probably be >>> removed. That's the old sampling profiler from Plan 9, and I don't >>> imagine we'll be using it again. (Let me know if I'm wrong, Ron.) >>> >>> Barret >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Akaros" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
