Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp417454pxv; Wed, 14 Jul 2021 07:01:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyz+0+4X1cdYXUZlR4bew0e4BBfX9YUS0sGfDCL9x8v59qCEX+61RUqoXykUX3flNbhxZ0 X-Received: by 2002:a5d:8198:: with SMTP id u24mr7272702ion.81.1626271311248; Wed, 14 Jul 2021 07:01:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626271311; cv=none; d=google.com; s=arc-20160816; b=QjZQkMXagHmJA7zIUczH6GdMp1PtzGXf+Ux7rmMQ6f+tf6l34ah8PmZEghM0Fo/L8s iO7bDr4EFKYulECNq9aGKuexpEAA3K7vKznG6qhoHE7Qr6WlwO+K55peh6C5bDxgGfOQ ZTSDck0kpiRbIBbB5MhweMN7xAKNDzQ6htzyAarD5i3pdu+BEBsocrL1baQ7GCWBFpi/ wKzHdhd4PyM2wwXA0nP4jxXxt3fa7jywy+AccKtXIwFzpEv10Ci7uD7KxhKEnyXFputb 4jrurX1xaFBKwrQwvFfVrUBsPJn+BweFhLl+SStEHh2etkpRJGXItMEfVm8qcBSMSFuM ld3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=qRPGNtzJWzOGXpSJPvpdCNRGRgva7qAtz0cCiCc6Zao=; b=vcBcdOmV92aEbTMB45APJPGcIN8l/DYmXaBsNOdFzdCH8+J1T/O1ZX31Jn/sJ3I9ML IyQXPoya25dJsCCuhJOLQOh0ZYIY5TuzX3aS31Tg/LLNFJJ5nKfT6LO/PHpDq3VXqkYx T16jukMkJKnuqqr0alnfYXvgsyTmRxfoEk8HRadhploJnemnc7UjvENqy2VJJTdvx5Oe kPdysA6w0mhO7Wa3oTTSo2WUvJtYIRCkbEjZ0SSrku+Oxb2Payh3qkKjw2zSdWxc1hh7 zthxPYKcJMmWDdmzg6iwkpxm4qCsWla+fXDMrNH7+lKPXO+nDJ6ac61key5nPRRnoe1p igtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IM0MNWWv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si2397106iob.0.2021.07.14.07.01.37; Wed, 14 Jul 2021 07:01:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IM0MNWWv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232029AbhGNODj (ORCPT + 99 others); Wed, 14 Jul 2021 10:03:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:47482 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231765AbhGNODj (ORCPT ); Wed, 14 Jul 2021 10:03:39 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7E284613C5; Wed, 14 Jul 2021 14:00:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626271247; bh=xGY4cSgMPI+T6Zv4LZaM0MnuIapjyecxgtZFl42X6mQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IM0MNWWv/4INkWFcLSgm0kg4IQ3zpcwuGpQ15LgAzwEAJluisAX97roEKU7yaX8rr vfBVIOKPOXJh8ulvMjeVGq0mvqDmATTHoqwqDvpl0hyVHDUDiDxUX2Pg5gF9H29Hbw k3p1lZxOmPTJBsa2bRZoBOCbD2tiEZskGjD8Gc3DOZR2S6y5bQnBh3yfSAIQh1SwDG UcaARyTFlZBDwISKBqjc1+QQMqtEZLA96QjUmr+obv3dxKFsXPow+zC/SWSEb/sizN 7tFDCC9XhfTeqij+O8cgHPuVVeb5eFX1Q5dt076vmoSAf+k6hLNQJTqvxk9qS31rgz eRIszr9Q1hTNQ== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 76DA2403F2; Wed, 14 Jul 2021 11:00:44 -0300 (-03) Date: Wed, 14 Jul 2021 11:00:44 -0300 From: Arnaldo Carvalho de Melo To: "Hunter, Adrian" Cc: Leo Yan , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Borislav Petkov , "x86@kernel.org" , "H. Peter Anvin" , Mathieu Poirier , Suzuki K Poulose , Mike Leach , "linux-perf-users@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "coresight@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v4 10/11] perf env: Set flag for kernel is 64-bit mode Message-ID: References: <20210711104105.505728-1-leo.yan@linaro.org> <20210711104105.505728-11-leo.yan@linaro.org> <20210713150953.GC748506@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Jul 14, 2021 at 10:59:49AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Jul 13, 2021 at 05:31:03PM +0000, Hunter, Adrian escreveu: > > > On Mon, Jul 12, 2021 at 03:14:35PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Sun, Jul 11, 2021 at 06:41:04PM +0800, Leo Yan escreveu: > > > > > +++ b/tools/perf/util/env.c > > > > > @@ -11,6 +11,7 @@ > > > > > #include > > > > > #include > > > > > > +int kernel_is_64_bit; > > > > > struct perf_env perf_env; > > > > > Why can't this be in 'struct perf_env'? > > > > Good question. I considered to add it in struct perf_env but finally I used this > > > way; the reason is this variable "kernel_is_64_bit" is only used during > > > recording phase for AUX ring buffer, and don't use it for report. So seems to > > > me it's over complexity to add a new field and just wander if it's necessary to > > > save this field as new feature in the perf header. > > > I think we store the arch, so if the "kernel_is_64_bit" calculation depends only on arch > > then I guess we don't need a new feature at the moment. > > So, I wasn't suggesting to add this info to the perf.data file header, > just to the in-memory 'struct perf_env'. > > And also we should avoid unconditionally initializing things that we may > never need, please structure it as: Oops, forgot these: > static void perf_env__init_kernel_mode(struct perf_env *env) > { > const char *arch = perf_env__raw_arch(env); > > if (!strncmp(arch, "x86_64", 6) || !strncmp(arch, "aarch64", 7) || > !strncmp(arch, "arm64", 5) || !strncmp(arch, "mips64", 6) || > !strncmp(arch, "parisc64", 8) || !strncmp(arch, "riscv64", 7) || > !strncmp(arch, "s390x", 5) || !strncmp(arch, "sparc64", 7)) > kernel_is_64_bit = 1; env->kernel_is_64_bit = 1; > else > kernel_is_64_bit = 0; env->kernel_is_64_bit = 0; > } > > > void perf_env__init(struct perf_env *env) > { > ... > env->kernel_is_64_bit = -1; > ... > } > > bool perf_env__kernel_is_64_bit(struct perf_env *env) > { > if (env->kernel_is_64_bit == -1) > perf_env__init_kernel_mode(env); > > return env->kernel_is_64_bit; > } > > One thing in my TODO is to crack down on the tons of initializations > perf does unconditionally, last time I looked there are lots :-\ > > - Arnaldo > > > > Combining the comment from Adrian in another email, I think it's good to add > > > a new field "compat_mode" in the struct perf_env, and this field will be > > > initialized in build-record.c. Currently we don't need to save this value into > > > the perf file, if later we need to use this value for decoding phase, then we > > > can add a new feature item to save "compat_mode" > > > into the perf file's header. > > > > If you have any different idea, please let me know. Thanks! -- - Arnaldo