From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26141 invoked by alias); 24 Oct 2013 04:26:14 -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 26126 invoked by uid 89); 24 Oct 2013 04:26:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f176.google.com Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 24 Oct 2013 04:26:12 +0000 Received: by mail-wi0-f176.google.com with SMTP id l12so8369538wiv.15 for ; Wed, 23 Oct 2013 21:26:09 -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=LHxib2DOPKaJQBBN2Xc7xbCXHGgoPpRIIH3OPWCRUgM=; b=iJmBhdjtX35bA3FqIZmyR4ElRKMWpodIOkSr7GAkXr8ynhSyHFNWOmhy3Um+dZPJzH aY8JNKip3C7YfXhLuIOGMOQYVm/XjqQj/pdB5Kt9sg2OTIdZHvRwmG0N/a+QWoukXQIc BbtKqp02mx67c0RUvHSYu3jYYHLYrjc+6BfvW0Gd/jYQCw/PUFIFxwVVC8CoMn1lOZG+ Ez9+FdL5kNgUas9nrbcmmADKCkeL+rn7dlvNQNL3OwlNEF21d9CWOgjmM7OIEiok+nk2 3B7NXJIEM8XOBNP8rM+PVmTrs47lhOoeISjStMmCoNZSDBohoQlXG+kirDpypfVOTAg+ gj0w== X-Gm-Message-State: ALoCoQmuPjbn8nOia1QE9YY2VwXxVWk2XZd5x+WJDzRoS5K4tR8C6HKWmmVeC6g+6g6bOUxZRNPh MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr315100wic.64.1382588769410; Wed, 23 Oct 2013 21:26:09 -0700 (PDT) Received: by 10.194.219.7 with HTTP; Wed, 23 Oct 2013 21:26:09 -0700 (PDT) In-Reply-To: <525D0D39.10404@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> <525D0D39.10404@hitachi.com> Date: Thu, 24 Oct 2013 04:26:00 -0000 Message-ID: Subject: Re: Re: Re: Regarding systemtap support for AArch64 From: Sandeepa Prabhu To: Masami Hiramatsu Cc: William Cohen , systemtap@sourceware.org, Deepak Saxena , Krishna Dani , Jakub Pavelek Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00092.txt.bz2 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 :( > > However, for debugging use, the performance degradation is not > so important. > >> Want to know the acceptance criteria for systemtap or perf to say >> 'kprobes/uprobes on an architecture' is complaint and good enough for >> tracing? > > I think there is no such criteria. The overhead problem depends on the > use-cases as I said above. If it is functional, it's enough to use by > perf/ftrace ;) Performance optimization can be done afterwords. > > Thank you, > > -- > Masami HIRAMATSU > IT Management Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu.pt@hitachi.com > >