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.
