Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3557444pxb; Mon, 25 Jan 2021 21:19:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzY1O1VrWAs/I1Jk0RHprAyNJhhyb+xw4adQFYjVDBT0vCsOXynMSLYfIBH1WTDg9Z+FhNA X-Received: by 2002:a05:6402:614:: with SMTP id n20mr3189487edv.358.1611638373099; Mon, 25 Jan 2021 21:19:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611638373; cv=none; d=google.com; s=arc-20160816; b=E3qHR+aaV5N4OjTI0yaR5kJwcHCP0wMKY4E1PZGxKqzg/odza5fIsVidKwuf5uL/e3 CCxM6iaBy8U/bAlL/+l3Zwzi2ZamFm4nTNWKJYvltN9fk3STkViwnsZDu1RBzmuyA/eg 8mq5znaWsXQRUjWBAVHda600id6M/wwQxCW5KRRZNQ2+NyOHh+ojPphcrkoxysC7Q1E2 qrYD9A3bwAu3bra3lJM7lmIfwUrz0g2zeCOYWrrj83gfS7GU/njtFBrtKYK2xYZWPXX6 ATlkVicwdEO1rGMLMDFA8u2x+e69HDGT0wlzsRiuJVBIgtvftEiTiMcfoZtJisplPE05 iLNA== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ww5KUVatmfw40DRXSZSjsU0K7HPXxhK4G7uFx/oOtAw=; b=SPUulczxekUN6GFDAJTUuk4JuEEpQZjVlfjGUD22RUXzRiBYYu1HN8s9CMrTgHDTkF 16l14dlsPpzFsPUr7uHCuSoyS79e9++qI6jFZYTaJej69hE8JnDwNdgfT8G58jDWzgoz uvus9kO0HnBenImukBDbuTycMdGHyd33QHvb5YybyrCWJM5fxGm3xSmGIyZZzrPjSB/m 7ZyQgJQP5Stjr1hIzZv+rgtuos6oqyeJZXVUsoB73n8FiKTFk+oWcxSrJ53heOY/sqsj qo24pPX7aTIQEqkThelSvtmEGJO8mr5C1AfLjz+lQcxOs3MCJ8+prmUe1UznQzPwynov KpUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VkONisoX; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l20si5102227ejx.471.2021.01.25.21.19.09; Mon, 25 Jan 2021 21:19:33 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=VkONisoX; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731699AbhAZFSV (ORCPT + 99 others); Tue, 26 Jan 2021 00:18:21 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:53924 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727177AbhAYJrp (ORCPT ); Mon, 25 Jan 2021 04:47:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611567961; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ww5KUVatmfw40DRXSZSjsU0K7HPXxhK4G7uFx/oOtAw=; b=VkONisoX9JhAHG0teH1TWxDe3tlM4aaC6hy2XaCQaRGOm/Xgi4++WSQq5Yz7vknoFIqoQo 6LcXOCTehO3AE72DOOKCylKSip00EAJ9qniJEE9kktKT1vadm1qrLzkFyqmDJ4Oj/S76n9 tZiAJ2jEEgNXPiCiUVJbzFVj6mwJg6M= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-124-hX-o1ps3OdCDSz5_v6BzJQ-1; Mon, 25 Jan 2021 04:45:59 -0500 X-MC-Unique: hX-o1ps3OdCDSz5_v6BzJQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6182E802B49; Mon, 25 Jan 2021 09:45:57 +0000 (UTC) Received: from krava (unknown [10.40.194.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED2AD60C0F; Mon, 25 Jan 2021 09:45:54 +0000 (UTC) Date: Mon, 25 Jan 2021 10:45:54 +0100 From: Jiri Olsa To: "Jin, Yao" Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com, ying.huang@intel.com Subject: Re: [PATCH v7] perf stat: Fix wrong skipping for per-die aggregation Message-ID: <20210125094554.GB245791@krava> References: <20210118040521.31003-1-yao.jin@linux.intel.com> <20210120220735.GE1798087@krava> <20210123225709.GB138414@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2021 at 01:47:54PM +0800, Jin, Yao wrote: > Hi Jiri, > > On 1/24/2021 6:57 AM, Jiri Olsa wrote: > > On Thu, Jan 21, 2021 at 12:21:36PM +0800, Jin, Yao wrote: > > > > sNIP > > > > > mask = hashmap__new(pkg_id_hash, pkg_id_equal, NULL); > > > d = cpu_map__get_die(cpus, cpu, NULL).die; > > > key = (size_t)d << KEY_SHIFT | s; /* s is socket id */ > > > if (hashmap__find(mask, (void *)key, NULL)) > > > *skip = true; > > > else > > > ret = hashmap__add(mask, (void *)key, (void *)1); > > > > > > If we use 'unsigned long' to replace 'size_t', it reports the build error for 32 bits: > > > > > > stat.c:320:23: warning: passing argument 1 of ‘hashmap__new’ from > > > incompatible pointer type [-Wincompatible-pointer-types] > > > mask = hashmap__new(pkg_id_hash, pkg_id_equal, NULL); > > > ^~~~~~~~~~~ > > > In file included from stat.c:16: > > > hashmap.h:75:17: note: expected ‘hashmap_hash_fn’ {aka ‘unsigned int > > > (*)(const void *, void *)’} but argument is of type ‘long unsigned int > > > (*)(const void *, void *)’ > > > > > > If we use "unsigned int", it's not good for 64 bits. So I still use 'size_t' in this patch. > > > > > > Any comments for this idea (using conditional compilation)? > > > > isn't it simpler to allocate the key then? like below > > (just compile tested) > > > > jirka > > > > Hmm, Each method has advantages and disadvantages. > > My method uses conditional compilation but it looks a bit complicated. The > advantage is it doesn't need to allocate the memory for key. > > If you need me to post v8, I'd love to. > > Anyway, either method is fine for me. :) I believe that the less ifdefs te better, if you could squash this change with your patch and send it, that'd be great SNIP > > + return *key & 0xffffffff; > > } > > -static bool pkg_id_equal(const void *key1, const void *key2, > > +static bool pkg_id_equal(const void *__key1, const void *__key2, > > void *ctx __maybe_unused) > > { > > - return (size_t)key1 == (size_t)key2; > > + uint64_t *key1 = (uint64_t*) __key1; > > + uint64_t *key2 = (uint64_t*) __key2; > > + > > + return *key1 == *key2; > > } > > static int check_per_pkg(struct evsel *counter, > > @@ -297,7 +309,7 @@ static int check_per_pkg(struct evsel *counter, > > struct hashmap *mask = counter->per_pkg_mask; > > struct perf_cpu_map *cpus = evsel__cpus(counter); > > int s, d, ret = 0; > > - size_t key; > > + uint64_t *key; > > *skip = false; > > @@ -338,7 +350,11 @@ static int check_per_pkg(struct evsel *counter, > > if (d < 0) > > return -1; > > - key = (size_t)d << 16 | s; > > + key = malloc(sizeof(*key)); > > + if (!key) > > + return -ENOMEM; > > + > > + *key = (size_t)d << 32 | s; > > Should be "*key = (uint64_t)d << 32 | s;"? yes, I missed this bit thanks, jirka