From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20983 invoked by alias); 7 Oct 2013 11:12:39 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 20971 invoked by uid 89); 7 Oct 2013 11:12:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f180.google.com Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com) (74.125.82.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 07 Oct 2013 11:12:37 +0000 Received: by mail-we0-f180.google.com with SMTP id q59so6429844wes.25 for ; Mon, 07 Oct 2013 04:12:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G7doUjGcyzbsy/LNDpchwDWsxEJESdqjMlF2GDHYGeg=; b=h3Qwy6XKgiGtWhqASTNE4nMeTQ4n2m5CFiJ51M+gFmL1lvWvTP1zAD26QvPUD8DOio b8KeRpecpxXmybV7hz4qeaSVFMaxDWWqdG0mk4avVvTKylFjz4kwhfwHg8jzFkDyTYcT Q46iv5Aeaw3Mx7FkhxwdBqNGE9LU/e0IEHoThXq6f0wx9vGQjkdi9ZXrVhIP3yjIhkRP GGC0VGXSOX+Gw3YKhTxGaeoIxFBcy+mEXbeKI0GFhlmr5h8KxSrrns0ZD2edW5rc0GPu jdnndh3PnnRVQlsAfkbBr4GXzM2Inv/0iBh5gHbFeUjnMKSBYfCwW+i2xPPwmAD1fDdO hRwA== X-Gm-Message-State: ALoCoQmSvyI3wsnckf16F/qbQu/eIyg4M+NSVfj8CAQbiiJpWtInr0d1P5iJQikZbghbtkx8G6WN MIME-Version: 1.0 X-Received: by 10.180.86.230 with SMTP id s6mr4363934wiz.64.1381144354274; Mon, 07 Oct 2013 04:12:34 -0700 (PDT) Received: by 10.194.219.7 with HTTP; Mon, 7 Oct 2013 04:12:34 -0700 (PDT) In-Reply-To: <525288DB.5060809@hitachi.com> References: <1380011243.3958.11921.camel@bordewijk.wildebeest.org> <52432F3B.4020503@redhat.com> <5248E391.3060306@hitachi.com> <52496A50.9090904@redhat.com> <524C025B.1060402@hitachi.com> <524D6A8A.3010700@hitachi.com> <524F8685.6040501@hitachi.com> <525288DB.5060809@hitachi.com> Date: Mon, 07 Oct 2013 11:12:00 -0000 Message-ID: Subject: Re: Re: Regarding systemtap support for AArch64 From: Sandeepa Prabhu To: Masami Hiramatsu Cc: William Cohen , systemtap@sourceware.org, Deepak Saxena Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00017.txt.bz2 On 7 October 2013 15:41, Masami Hiramatsu wrote: > (2013/10/07 18:50), Sandeepa Prabhu wrote: >> On 5 October 2013 08:54, Masami Hiramatsu >> 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 > >