Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5156128pxv; Tue, 20 Jul 2021 21:34:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTHTkZNYkTPKcqaRlII7qTwqbgb489z2QaX13EjPs7BgkET2YznmPdPTNwp8e9u27x8FOK X-Received: by 2002:a17:906:4d08:: with SMTP id r8mr35748569eju.464.1626842073836; Tue, 20 Jul 2021 21:34:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626842073; cv=none; d=google.com; s=arc-20160816; b=M/AgtbJKmt8p4hju8xGO9qp3u72QyM6yY2o0cNikJ9K46TiggfR1x7uJMAHx28BiXP fx3Pvp881W3A8WL2VYx7y62hydIf3d4J5nHKel9DfPysykhg7C8AT7aM8x2601LOA5SH 1e/0V2RmsaoC7PS7m13nUyR2+b3czszWrfrZAK7FM/fOyfck0hE7DJXiEjo+2yIaw1BY v7wai6ZsqMHzBw9gDx9Ins/NdxGk0CZbAJOQG5rt7WhM/CQhOlxHoXNO5U0bA6YlGGKQ 4oI1vHM7Vg3LuLrpdqGtYOaGh0M/FPgxzBe1N4RTkXGdLLGEJyxiRkMk6aW5oAKGJt0J 920g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=DS1fInHOulwoBkBCuBvaPDyUEOMRAoPipVLgu19HBFc=; b=hkXDx0Z7fIqhg3DG3Fgj3MR/MwORDipq3Lu/1ivHtun6D1xR3Tp/S2hx/+ArkHQZeb jJd82XQKmmVQQEgORCJ8vDjyPelGXzBnKKyf3v4+0bwFO3DPORiKpLOWg5QwiEvzVJm+ LONaM2hUua895e5IewBmjtu9bL98XR5/d8Jy+qW7tnc9aifYin4nXLjW2sCN1z2zdeyK AmaAJ1E5Ww+OkIgL+9MmkWYw05fXT6LxFfmxVA4Y9jo/BtEgVzb84caFzYDNY2Fc6Ea4 fffkoMe4ob6O731tmOeiXLfJsQw1QegIgG+n3psA4ZHnjf1ayejXW9lfAxBNOq7gQrdh /9Jg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g13si1741030ejo.277.2021.07.20.21.33.58; Tue, 20 Jul 2021 21:34:33 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232035AbhGUDt5 (ORCPT + 99 others); Tue, 20 Jul 2021 23:49:57 -0400 Received: from mga01.intel.com ([192.55.52.88]:11313 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231363AbhGUDtm (ORCPT ); Tue, 20 Jul 2021 23:49:42 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="233162580" X-IronPort-AV: E=Sophos;i="5.84,257,1620716400"; d="scan'208";a="233162580" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 21:30:15 -0700 X-IronPort-AV: E=Sophos;i="5.84,257,1620716400"; d="scan'208";a="501139482" Received: from yjin15-mobl1.ccr.corp.intel.com (HELO [10.238.4.147]) ([10.238.4.147]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 21:30:13 -0700 Subject: Re: [PATCH v3 3/3] perf tools: Enable on a list of CPUs for hybrid To: Jiri Olsa 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 References: <20210712071235.28533-1-yao.jin@linux.intel.com> <20210712071235.28533-4-yao.jin@linux.intel.com> From: "Jin, Yao" Message-ID: <598463ae-0bb0-7609-407b-4822112b2093@linux.intel.com> Date: Wed, 21 Jul 2021 12:30:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On 7/20/2021 5:16 PM, Jiri Olsa wrote: > On Tue, Jul 20, 2021 at 03:07:02PM +0800, Jin, Yao wrote: > > SNIP > >> >> OK, evlist__fix_cpus() is better, use this name in v4. >> >>>> +{ >>>> + struct perf_cpu_map *cpus; >>>> + struct evsel *evsel, *tmp; >>>> + struct perf_pmu *pmu; >>>> + int ret, unmatched_count = 0, events_nr = 0; >>>> + >>>> + if (!perf_pmu__has_hybrid() || !cpu_list) >>>> + return 0; >>>> + >>>> + cpus = perf_cpu_map__new(cpu_list); >>>> + if (!cpus) >>>> + return -1; >>>> + >>>> + evlist__for_each_entry_safe(evlist, tmp, evsel) { >>>> + struct perf_cpu_map *matched_cpus, *unmatched_cpus; >>>> + char buf1[128], buf2[128]; >>>> + >>>> + pmu = perf_pmu__find_hybrid_pmu(evsel->pmu_name); >>>> + if (!pmu) >>>> + continue; >>>> + >>>> + ret = perf_pmu__cpus_match(pmu, cpus, &matched_cpus, >>>> + &unmatched_cpus); >>>> + if (ret) >>>> + goto out; >>>> + >>>> + events_nr++; >>>> + >>>> + if (matched_cpus->nr > 0 && (unmatched_cpus->nr > 0 || >>>> + matched_cpus->nr < cpus->nr || >>>> + matched_cpus->nr < pmu->cpus->nr)) { >>>> + perf_cpu_map__put(evsel->core.cpus); >>>> + perf_cpu_map__put(evsel->core.own_cpus); >>>> + evsel->core.cpus = perf_cpu_map__get(matched_cpus); >>>> + evsel->core.own_cpus = perf_cpu_map__get(matched_cpus); >>> >>> I'm bit confused in here.. AFAIUI there's 2 evsel objects create >>> for hybrid 'cycles' ... should they have already proper cpus set? >>> >> >> For 'cycles', yes two evsels are created automatically. One is for atom CPU >> (e.g. 8-11), the other is for core CPU (e.g. 0-7). In this example, these 2 >> evsels have already the cpus set. > > hum, so those evsels are created with pmu's cpus, right? > Yes, that's right. But we also check and adjust the evsel->cpus by using user's cpu list on hybrid (what the evlist__use_cpu_list() does). >> >> While the 'cpus' here is just the user specified cpu list. >> cpus = perf_cpu_map__new(cpu_list); > > then I think they will be changed by evlist__create_maps > with whatever user wants? > No, it will not be changed by evlist__create_maps. In evlist__create_maps(), evlist->core.has_user_cpus = !!target->cpu_list && !target->hybrid; It disables has_user_cpus for hybrid. So in __perf_evlist__propagate_maps, they will not be changed by evlist->cpus. if (!evsel->own_cpus || evlist->has_user_cpus) { perf_cpu_map__put(evsel->cpus); evsel->cpus = perf_cpu_map__get(evlist->cpus); > could we just change __perf_evlist__propagate_maps to follow > pmu's cpus? > In __perf_evlist__propagate_maps, it has already followed pmu's cpus because the evlist->has_user_cpus is false for hybrid. Thanks Jin Yao > jirka > >> >> We need to check that the cpu in 'cpus' is available on hybrid pmu or not >> and adjust the evsel->core.cpus according the matching results. >> >>>> + >>>> + if (unmatched_cpus->nr > 0) { >>>> + cpu_map__snprint(matched_cpus, buf1, sizeof(buf1)); >>>> + pr_warning("WARNING: use %s in '%s' for '%s', skip other cpus in list.\n", >>>> + buf1, pmu->name, evsel->name); >>>> + } >>>> + } >>>> + >>>> + if (matched_cpus->nr == 0) { >>>> + evlist__remove(evlist, evsel); >>>> + evsel__delete(evsel); >>>> + >>>> + cpu_map__snprint(cpus, buf1, sizeof(buf1)); >>>> + cpu_map__snprint(pmu->cpus, buf2, sizeof(buf2)); >>>> + pr_warning("WARNING: %s isn't a '%s', please use a CPU list in the '%s' range (%s)\n", >>>> + buf1, pmu->name, pmu->name, buf2); >>>> + unmatched_count++; >>>> + } >>> >>> hum, should we rather fail in here? >>> >> >> perf stat -e cpu_core/cycles/,cpu_atom/instructions/ -C11 >> >> CPU11 is atom CPU so the evsel 'cpu_core/cycles/' is failed but cpu_atom/instructions/ is OK. >> >> Don't we report the partially successful event? >> >> Thanks >> Jin Yao >> >>> jirka >>> >> >