This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Re: Re: Regarding systemtap support for AArch64
- From: Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: William Cohen <wcohen at redhat dot com>, systemtap at sourceware dot org, Deepak Saxena <dsaxena at linaro dot org>, Krishna Dani <krishna dot mohan at linaro dot org>, Jakub Pavelek <jakub dot pavelek at linaro dot org>
- Date: Thu, 24 Oct 2013 09:56:09 +0530
- Subject: Re: Re: Re: Regarding systemtap support for AArch64
- Authentication-results: sourceware.org; auth=none
- References: <CA+b37P3S4adOJe+S1RWKVDEzeVLG2Oa4EFqYgeH4cU6SNmvtEQ at mail dot gmail dot com> <1380011243 dot 3958 dot 11921 dot camel at bordewijk dot wildebeest dot org> <52432F3B dot 4020503 at redhat dot com> <CA+b37P13t44vQfS3RwxkCowgqYBAHyUHCNJQtGqxmrqnt_rw6Q at mail dot gmail dot com> <5248E391 dot 3060306 at hitachi dot com> <52496A50 dot 9090904 at redhat dot com> <CA+b37P31Zz3F0SGJt_M_3T2GxCm6zn5K4b56oeoR-qMBF=wjDg at mail dot gmail dot com> <524C025B dot 1060402 at hitachi dot com> <CA+b37P0i8Ms8u=BcTAMfGGm+bSAYQO+OM-+qTiHSPRysMRMHfg at mail dot gmail dot com> <524D6A8A dot 3010700 at hitachi dot com> <CA+b37P2xSXfQ07KJ7a5B0AQxZGaj0zSA4=5JXfVA0uO+diTc9g at mail dot gmail dot com> <524F8685 dot 6040501 at hitachi dot com> <CA+b37P1EQPZZF1AvJc4kYobPrpk1bRzCLA513EUPNX_j=OBYwQ at mail dot gmail dot com> <525288DB dot 5060809 at hitachi dot com> <CA+b37P0eAciYDp8Ztoxy58KMCQ-GQhOR4VZBWrzbC_AXvMmixQ at mail dot gmail dot com> <525D0D39 dot 10404 at hitachi dot com>
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 :(
>
> 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
>
>