From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11B25C001B0 for ; Mon, 7 Aug 2023 14:06:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231622AbjHGOGw (ORCPT ); Mon, 7 Aug 2023 10:06:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232759AbjHGOGm (ORCPT ); Mon, 7 Aug 2023 10:06:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26A041FF3 for ; Mon, 7 Aug 2023 07:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691417094; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8Nlu9SHTk8pF76iz8mRyg8hI9jWId+zKXclHtiFUBI8=; b=O/YtG1Brpbu0YxtCjhLydR5vMAwGiXrmj3CDLPxs+5eiBFqfowpKvjnW0XZnXAzSCxlqOs o1dxSIY81VZ+GJ2EbBOQToYWtBO42AVEtItrk1BzyGt2Y9ATeo+jmd313Vt1+FRiOsGYbp a7Oy0t9s6nNS+zFW9G4lSVCxGFuwr6E= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-196-7laFvo-9Njerfwt0h5DW3Q-1; Mon, 07 Aug 2023 10:04:50 -0400 X-MC-Unique: 7laFvo-9Njerfwt0h5DW3Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 81BA2830F5B; Mon, 7 Aug 2023 14:03:51 +0000 (UTC) Received: from alecto.usersys.redhat.com (unknown [10.45.225.231]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FF612026D4B; Mon, 7 Aug 2023 14:03:46 +0000 (UTC) Date: Mon, 7 Aug 2023 16:03:43 +0200 From: Artem Savkov To: Arnaldo Carvalho de Melo Cc: Jesper Dangaard Brouer , Andrii Nakryiko , Namhyung Kim , Adrian Hunter , Alexander Shishkin , Ian Rogers , Ingo Molnar , Jiri Olsa , Mark Rutland , Masami Hiramatsu , Milian Wolff , Peter Zijlstra , Linux Kernel Mailing List Subject: Re: [PATCH 1/1] Revert "perf report: Append inlines to non-DWARF callchains" Message-ID: <20230807140343.GA910089@alecto.usersys.redhat.com> References: <20230802074335.GA622710@alecto.usersys.redhat.com> <20230807110008.GA886657@alecto.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 07, 2023 at 10:34:44AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Aug 07, 2023 at 01:00:08PM +0200, Artem Savkov escreveu: > > On Wed, Aug 02, 2023 at 09:43:40AM +0200, Artem Savkov wrote: > > > Hi Arnaldo, > > > > > > On Tue, Aug 01, 2023 at 06:42:47PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Hi Artem, > > > > > > > > Can you please double check this? I reproduced with: > > > > > > > > git checkout 46d21ec067490ab9cdcc89b9de5aae28786a8b8e > > > > build it > > > > perf record -a -g sleep 5s > > > > perf report > > > > > > > > Do you get the same slowness and then reverting it, i.e. just > > > > going to HEAD~ and rebuilding getting a fast 'perf report' startup, i.e. > > > > without the inlines in the callchains? > > > > > > With a simple test like this I definitely get a slowdown, but not sure > > > if it can be called excessive. > > > > > > Below are the times I got by running 'time perf report' and hitting 'q' > > > during load so that it quits as soon as it is loads up. Tested on a > > > freshly updated fedora 38. > > > > My bad, I had wrong debuginfo installed for the kernel I tested. I can > > reproduce it with the correct one. Looks like vmlinux is just too much > > for addr2line. Maybe we can skip it but leave other inlines in, like so: > > That is a possibilit, and probably we could make it cheaper by looking > at the cpumode, avoiding calling addr2line when we didn't makage to > resolve the symbol, etc. > > We also may want to have this as an option that has to be explicitely > enabled, like --resolve-inlines, as this will add overhead no matter if > we stop calling addr2line and do it more efficiently, etc. Sounds good, I'll look into it. > Fact is, we're late in the 6.5 schedule, so the best thing now is to > just revert the patch and then try again later, ok? Yes, sure. > - Arnaldo > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > index 11de3ca8d4fa7..fef309cd401f7 100644 > > --- a/tools/perf/util/machine.c > > +++ b/tools/perf/util/machine.c > > @@ -2388,7 +2388,9 @@ static int add_callchain_ip(struct thread *thread, > > ms.map = map__get(al.map); > > ms.sym = al.sym; > > > > - if (!branch && append_inlines(cursor, &ms, ip) == 0) > > + if (!branch && ms.map && ms.map->dso && > > + strcmp(ms.map->dso->short_name, "[kernel.vmlinux]") && > > + append_inlines(cursor, &ms, ip) == 0) > > goto out; > > > > srcline = callchain_srcline(&ms, al.addr); > > > > > > - Arnaldo > > > > > > > > ---- > > > > > > > > This reverts commit 46d21ec067490ab9cdcc89b9de5aae28786a8b8e. > > > > > > > > The tests were made with a specific workload, further tests on a > > > > recently updated fedora 38 system with a system wide perf.data file > > > > shows 'perf report' taking excessive time, so lets revert this until a > > > > full investigation and improvement on the addr2line support code is > > > > made. > > > > > > > > Cc: Andrii Nakryiko > > > > Cc: Artem Savkov > > > > Cc: Namhyung Kim > > > > Cc: Adrian Hunter > > > > Cc: Alexander Shishkin > > > > Cc: Ian Rogers > > > > Cc: Ingo Molnar > > > > Cc: Jiri Olsa > > > > Cc: Mark Rutland > > > > Cc: Masami Hiramatsu > > > > Cc: Milian Wolff > > > > Cc: Peter Zijlstra > > > > Signed-off-by: Arnaldo Carvalho de Melo > > > > --- > > > > tools/perf/util/machine.c | 5 ----- > > > > 1 file changed, 5 deletions(-) > > > > > > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > > > index 4e62843d51b7dbf9..f4cb41ee23cdbcfc 100644 > > > > --- a/tools/perf/util/machine.c > > > > +++ b/tools/perf/util/machine.c > > > > @@ -45,7 +45,6 @@ > > > > > > > > static void __machine__remove_thread(struct machine *machine, struct thread_rb_node *nd, > > > > struct thread *th, bool lock); > > > > -static int append_inlines(struct callchain_cursor *cursor, struct map_symbol *ms, u64 ip); > > > > > > > > static struct dso *machine__kernel_dso(struct machine *machine) > > > > { > > > > @@ -2385,10 +2384,6 @@ static int add_callchain_ip(struct thread *thread, > > > > ms.maps = maps__get(al.maps); > > > > ms.map = map__get(al.map); > > > > ms.sym = al.sym; > > > > - > > > > - if (!branch && append_inlines(cursor, &ms, ip) == 0) > > > > - goto out; > > > > - > > > > srcline = callchain_srcline(&ms, al.addr); > > > > err = callchain_cursor_append(cursor, ip, &ms, > > > > branch, flags, nr_loop_iter, > > > > -- > > > > 2.41.0 > > > > > > > > > > -- > > > Artem > > > > -- > > Artem > > > > -- > > - Arnaldo > -- Artem