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.
