Re: Regarding systemtap support for AArch64

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

(2013/10/24 13:26), Sandeepa Prabhu wrote:
> On 15 October 2013 15:09, Masami Hiramatsu
> <masami.hiramatsu.pt@hitachi.com> wrote:
>> (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.
> Hmm, my worry is whether we can really measure and improve performance
> or not -running on foundation model, do not have real hardware access
> right now :(

Ah, right! :)
OK, so I think this should good to be done after real hardware is out.

Thank you!


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