This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Regarding systemtap support for AArch64
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>
- 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 14:08:02 +0900
- Subject: 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> <CA+b37P1Ep9vySUw7vozAgdgEwwq6mEnZEaf1kCKugdGbdOh7Vw at mail dot gmail 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