This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Regarding systemtap support for AArch64


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.

>
> [...]
>>>>>  - 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 :-)
>
> [...]
>>>> Masami,
>>>> Couple of questions:
>>>> 1. My changes reside in arm/arm64 only right now, does it make sense
>>>> to publish on LKML so that core kprobes developers can review?
>>>
>>> Of course, it is always helpful for us :)
>>>
>>>> 2. Wanted to change sample/kprobes/kprobe_example.c to check for the
>>>> missing case of ARM & ARM64 and print the relevant info. Can this
>>>> change be as part of same series (if going on LKML)?
>>>
>>> Yeah, it is better to update it within the series.
>> OK, I will do that, and CC LKML from v2.
>
> thanks :)
>
>>>> Thanks a lot for your review, I would also need help on validation for
>>>> my work, please let me know if our repo holds good for systemtap
>>>> validation. I am interested in using fedora on v8 model, please
>>>> provide me some instructions to get the packages.
>>>
>>> Thank you !
>>
>> 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'.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]