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 X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=DATE_IN_PAST_12_24, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CF7EC04EBA for ; Tue, 27 Nov 2018 12:35:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 36884208E4 for ; Tue, 27 Nov 2018 12:35:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YkDSc2Wq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36884208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729415AbeK0Xdp (ORCPT ); Tue, 27 Nov 2018 18:33:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:34008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726663AbeK0Xdo (ORCPT ); Tue, 27 Nov 2018 18:33:44 -0500 Received: from quaco.infradead.org (unknown [190.15.121.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 133B721104; Tue, 27 Nov 2018 12:35:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543322156; bh=SAqhFFh+ig7tJ2zRM9jio72AcGI0+FeW9BwKg8y/D3Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YkDSc2WqCrQeMFpQ1xmSA9pF0Kqr5TmV5uD+pHlqyLqwjuJmlT4YFaVBa64aX58CW 3ixKcRKK7yhYKaOaLRjq5nnI+tMmwJ3u5Ok09TfpjQ69vIFE7mGENo3iQotEdBMGhR 5tj1jHKGJSWzB6GN2n6Vcv9V0PR95LJi67+1nWsE= Received: by quaco.infradead.org (Postfix, from userid 1000) id 467B741116; Mon, 26 Nov 2018 16:02:17 -0300 (-03) Date: Mon, 26 Nov 2018 16:02:17 -0300 From: Arnaldo Carvalho de Melo To: "Hunter, Adrian" Cc: Jiri Olsa , Andi Kleen , "linux-kernel@vger.kernel.org" , "leo.yan@linaro.org" , David Miller , Mathieu Poirier Subject: Re: [PATCH 1/5] perf tools: Add fallback functions for cases where cpumode is insufficient Message-ID: <20181126190217.GC18491@kernel.org> References: <20181031091043.23465-1-adrian.hunter@intel.com> <20181031091043.23465-2-adrian.hunter@intel.com> <20181105172946.GH11147@kernel.org> <363DA0ED52042842948283D2FC38E4649C313381@IRSMSX106.ger.corp.intel.com> <20181105193615.GG7077@kernel.org> <363DA0ED52042842948283D2FC38E4649C3133B4@IRSMSX106.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <363DA0ED52042842948283D2FC38E4649C3133B4@IRSMSX106.ger.corp.intel.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, Nov 05, 2018 at 07:53:17PM +0000, Hunter, Adrian escreveu: > > -----Original Message----- > > From: Arnaldo Carvalho de Melo [mailto:acme@kernel.org] > > Sent: Monday, November 5, 2018 9:36 PM > > To: Hunter, Adrian > > Cc: Jiri Olsa ; Andi Kleen ; linux- > > kernel@vger.kernel.org; leo.yan@linaro.org; David Miller > > ; Mathieu Poirier > > Subject: Re: [PATCH 1/5] perf tools: Add fallback functions for cases where > > cpumode is insufficient > > > > Em Mon, Nov 05, 2018 at 07:21:44PM +0000, Hunter, Adrian escreveu: > > > > In Monday, November 5, 2018 7:30 PM, Arnaldo Carvalho de Melo wrote > > > > > > > +struct map *thread__find_map_fallback(struct thread *thread, u8 > > > > cpumode, > > > > > + u64 addr, struct addr_location *al) { > > > > > > You named one as _fallback... > > > > > > > + struct map *map = thread__find_map(thread, cpumode, addr, al); > > > > > + struct machine *machine = thread->mg->machine; > > > > > + u8 addr_cpumode = machine__addr_cpumode(machine, cpumode, > > > > addr); > > > > > + > > > > > + if (map || addr_cpumode == cpumode) > > > > > + return map; > > > > > + > > > > > + return thread__find_map(thread, addr_cpumode, addr, al); } > > > > > + > > > > > struct symbol *thread__find_symbol(struct thread *thread, u8 > > cpumode, > > > > > u64 addr, struct addr_location *al) { @@ - > > > > 1585,6 +1603,15 @@ > > > > > struct symbol *thread__find_symbol(struct thread *thread, u8 > > cpumode, > > > > > return al->sym; > > > > > } > > > > > > > +struct symbol *thread__find_symbol_fb(struct thread *thread, u8 > > > > cpumode, > > > > > + u64 addr, struct addr_location *al) > > > > > > ... and the other as _fb, make it consistent, please. > > > > > ok > > > > > > > +{ > > > > > + al->sym = NULL; > > > > > + if (thread__find_map_fallback(thread, cpumode, addr, al)) > > > > > + al->sym = map__find_symbol(al->map, al->addr); > > > > > + return al->sym; > > > > > +} > > > > > > > /* > > > > > * Callers need to drop the reference to al->thread, obtained in > > > > > * machine__findnew_thread() > > > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > > > > index 111ae858cbcb..04edc0eac376 100644 > > > > > --- a/tools/perf/util/machine.c > > > > > +++ b/tools/perf/util/machine.c > > > > > @@ -2542,6 +2542,46 @@ int machine__get_kernel_start(struct > > > > > machine > > > > *machine) > > > > > return err; > > > > > } > > > > > > > +/* > > > > > + * machine__single_ku_as - Machine has same address space for > > > > > +kernel > > > > and user. > > > > > + * @machine: machine object > > > > > + * > > > > > + * Some architectures have a single address space for kernel and > > > > > +user addresses, > > > > > + * which makes it possible to determine if an address is in > > > > > +kernel space or user > > > > > + * space. > > > > > + */ > > > > > +static bool machine__single_ku_as(struct machine *machine) { > > > > > + return strcmp(perf_env__arch(machine->env), "sparc"); } > > > > > > Can we avoid having this strcmp be done repeatedly? > > > > > It is only done if there are mapping errors > > > > > > Can we avoid having this strcmp be done repeatedly? I.e. just make > > > this a > > > > boolean initialized at session start, when machine->env is setup, so > > > > we'd > > > > have: > > > > > > machine->single_address_space > > > > > > Instead of a function? > > > > > Sure thing. Have you sent an update to this patch series addressing the concerns? I think that renaming that _fb to __fallback and having this machine->single_address_space is what is missing, I'll try to take a stab at this now and have it in my perf/core branch soon. But you have this already done, please send it. - Arnaldo