The way it is now, /prof/kptrace looks like dmesg. Data does not vanish at first retrieval. Data goes in there, kernel side, via trace_printk() (TRACEME calls that). The user can also add data in there:
$ echo Fubar > /prof/kptrace Data pumped from user side, has not bracktrace with it (will be pointing to the same trace all the time ☺). A circular buffer behind it, takes care of dropping old data if necessary (default buffer size if 512KB). On Thu, Nov 5, 2015 at 2:22 PM, Davide Libenzi <[email protected]> wrote: > Example: > > / $ cat /prof/kptrace > [ 8.102085467]:cpu0: kern/drivers/dev/kprof.c(227) > Backtrace: > #01 [<0xffffffffc207233e>] in trace_printk > #02 [<0xffffffffc207250f>] in kprof_init > #03 [<0xffffffffc203d19c>] in devtabinit > #04 [<0xffffffffc200b40d>] in kernel_init > > > > On Thu, Nov 5, 2015 at 1:14 PM, Davide Libenzi <[email protected]> > wrote: > >> 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.
