Re: Re: Regarding systemtap support for AArch64

[Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>]

On 7 October 2013 15:41, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/10/07 18:50), Sandeepa Prabhu wrote:
>> On 5 October 2013 08:54, Masami Hiramatsu
>> <masami.hiramatsu.pt@hitachi.com> wrote:
>>> (2013/10/04 12:24), 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?
Want to know the acceptance criteria for systemtap or perf to say
'kprobes/uprobes on an architecture' is complaint and good enough for
tracing?

>
>>> [...]
>>>>>>>  - probes-*.c is not good name for the simulator. those should have
>>>>>>>    better name.
>>>>>> May be decode-arm64.c? Originally I had decode-* but the logic is
>>>>>> limited to kprobes and uprobes only so renamed that way.  Other cases
>>>>>> like jump_labels, use different decoding, and may not share same code.
>>>>>
>>>>> The decoding table will be different from other usecase, but I think
>>>>> simulator code can be shared (and must be). It may just get the address,
>>>>> instruction, and registers, not the kprobe.
>>>> When we wrote at Linaro, our plan was to share simulation calls
>>>> between kprobes and uprobes, and planned to use 'struct kprobes' for
>>>> both the frameworks, this is how it was done on "arch/arm/kernel/"
>>>> effectively.
>>>
>>> Uh, I should review arm32 again...
>>>
>>>> If more frameworks can use it (as it seems) I change it to accept
>>>> opcode, pc value and saved pt_regs and avoid kprobe struct altogether.
>>>> Also, we are starting on uprobes at Linaro, so it won't be too long
>>>> before we start thinking about that too ;-)
>>>
>>> Since kprobes data structure includes many information which is not related
>>> to the simulation, I'd like to keep it away from that.
>> Yup, can simulate without that. I will avoid kprobe struct from
>> simulators and keep it cleaner :-)
>
> Good ;)
>
> [...]
>>>> Question:
>>>> I am working on v2 patchset based on comments, for next week to post,
>>>> do you have basic aarch64 setup (fast-model/hardware), ARM v8-ARM etc?
>>>> I mean, how about sharing some efforts with me(Linaro) going further?
>>>
>>> Yeah, I have a foundation-model simulator, I just need to set it up.
>>>
>>>> Most work shall go through LAKML so you may have to subscribe to that
>>>> ;),  but do you mind working on Linaro hosted public git ? we can lay
>>>> out a plan then. After kprobes, we have much work on uprobes in queue
>>>> (both 32-bit and 64-bit user-space) and your insights help us, since
>>>> you are one of the maintainers of both subsystems.
>>>
>>> Oh, OK. I'll subscribe it, and, yeah, linaro public git should be
>>> better place to work with :)
>> Thanks!!  I will reach out to leads in Linaro regarding read/write
>> access and stuff (guess it's read-only right now)
>> You can have a look at following Linaro cards (agile projecting tracking):
>>    https://cards.linaro.org/browse/KWG-13
>>    https://cards.linaro.org/browse/CARD-564
>> If you find them interesting, you may subscribe to these by creating a
>> login, and clicking on  more -> 'watch this issue'.
>
> Looks nice :) I'll do that.
>
> Thank you!
>
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>