Re: Re: Re: Regarding systemtap support for AArch64

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

(2013/10/07 20:12), Sandeepa Prabhu wrote:
>>>>>>>>  - Is it really need to use spinlock to protect break_hook?
>>>>>>> Any cpu can remove breakpoint hooks right, and traversal happen in
>>>>>>> debug exception context so mutex are not safe (can sleep/schedule out)
>>>>>>> in debug exception.
>>>>>>
>>>>>> I don't think we need to remove the breakpoint hooks after starting
>>>>>> up the kernel. If we use the spinlock there, we'll pay a big cost
>>>>>> because of the lock contention.
>>>>> Not in kprobes. But kgdb can remove breakpoint handler and use same
>>>>> API. or atleast while providing an api we should not assume race
>>>>> cannot happen right?
>>>>
>>>> In that case, we'd better add a wrapper handler for kgdb so that
>>>> the list isn't updated even if the kgdb removes its handler.
>>>>
>>>>> And there wont be much lock contention, i'ts only if the debug
>>>>> framework (like kgdb) is wrapping-up, not is normal use-case.
>>>>
>>>> Hmm, it seems that the spinlock is locked while handling a breakpoint.
>>>> This will cause a bad performance issue when we put many kprobes
>>>> on SMP system.
>>> arm maintainers prefer a reader/writer spin-locks, so there wont be
>>> lock contention in debug path, each instance of kprobe hook trap (on
>>> any CPU) would be a reader, not blocking.
>>
>> OK for the first step, and it eventually should be fixed to lockless.
>> (depends on the performance improvement)
> Hmm, is there a performance requirement for systemtap or perf? -like
> how much time each test suite should consume etc?

Basically, for the enterprise use, we aims to get less than 5% loss
of runtime performance. Of course it depends on the configuration.
This requirement comes from the usage of tracing, it's usually used
as a "flight-recorder" in such system. For analyzing the root cause
of the trouble, some fundamental events are always recorded into a
memory buffer. When encountering a trouble, the buffer will be dumped,
and trouble shooting team analyzes it.

Thus, I'd like to make the performance overhead of tracing as
small as possible.

However, for debugging use, the performance degradation is not
so important.

> Want to know the acceptance criteria for systemtap or perf to say
> 'kprobes/uprobes on an architecture' is complaint and good enough for
> tracing?

I think there is no such criteria. The overhead problem depends on the
use-cases as I said above. If it is functional, it's enough to use by
perf/ftrace ;) Performance optimization can be done afterwords.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com