From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3280 invoked by alias); 24 Oct 2013 05:08:13 -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 3265 invoked by uid 89); 24 Oct 2013 05:08:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail9.hitachi.co.jp Received: from mail9.hitachi.co.jp (HELO mail9.hitachi.co.jp) (133.145.228.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Oct 2013 05:08:10 +0000 Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id E08B437C86; Thu, 24 Oct 2013 14:08:07 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id r9O587jH016153; Thu, 24 Oct 2013 14:08:07 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r9O5868i011570; Thu, 24 Oct 2013 14:08:07 +0900 Received: from gmml27.itg.hitachi.co.jp (unknown [158.213.165.130]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 8B77649005C; Thu, 24 Oct 2013 14:08:06 +0900 (JST) Received: from [10.198.208.51] by gmml27.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id r9O586H5820442; Thu, 24 Oct 2013 14:08:06 +0900 Message-ID: <5268AB32.2010007@hitachi.com> Date: Thu, 24 Oct 2013 05:08:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sandeepa Prabhu Cc: William Cohen , systemtap@sourceware.org, Deepak Saxena , Krishna Dani , Jakub Pavelek Subject: Re: Regarding systemtap support for AArch64 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> <525D0D39.10404@hitachi.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00093.txt.bz2 (2013/10/24 13:26), Sandeepa Prabhu wrote: > On 15 October 2013 15:09, Masami Hiramatsu > 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