Received: by 10.223.185.116 with SMTP id b49csp6169389wrg; Thu, 8 Mar 2018 03:03:07 -0800 (PST) X-Google-Smtp-Source: AG47ELvv1dEiTtNtr2EaIfiqPuBHTVTEDE6dW/JZdtlMNv7qecZ4ZgytC5HOmM5Z2i8SF0JUig0O X-Received: by 10.167.129.24 with SMTP id b24mr25868567pfi.183.1520506987049; Thu, 08 Mar 2018 03:03:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520506987; cv=none; d=google.com; s=arc-20160816; b=O3jA3Z5jCVj3RRJ6LXSic6ADCTX2NhPgVBD/wr6OOAelyFI/u+fPrhXLLncXWrHpNx sg0noKFI4cvU/E4GAT7pIRVEuoNDNatuR14YGtlvABPQ44qQ8t1nfB0X4MGz8M0QJox/ rBhHmepbLNoyCTT1SUsnrsKslj60y00j6DKlmbiBycohvbfUhfS9lOw6cr+e0nLq/Qbi vn6dnwnaxzMcr1lQRNCl4iGXwLjlEiqvhirP3jBFeoYGiE51folAtmoPlQMJCMgHY6nS SM2WAuoyZrj0wi/KAltUiB1b+9OouWBzXuxBk5YQiRedSOAIDyiruhjuKFMzALUvuNbE mSMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=AvCYBm8GxSXk+cmu9prxNw3JgKFZSFox9BfHGmoU+no=; b=MrFASFOD7eYSAwOiOVLIN7ivMS2JJaKfQP8nNuLQ1X7K9W5y+OxbMbOVa71mgGSfw6 prGUAHWpyb3hqSu1sQ8I5XkOQjdyqh4LJajsTU7wpk0JZvY5PoAhR9s0p+nrMRkQEdG+ I31izVYOmy9mXVk36EeAMwHKYLm2evIQGBcPzgAnhjyD3ALVAhHnCxwX37aScyN67IYU cYb/97+VfeD2QJu5S4VHgUb/vmGnXuwWRcQXhQ/bnHiwubsqwvDBhtdt5fR88DVdRCVi AKPNEdsNvm6kHRTZc2YPYUtA4AJhblqGQNJs8ITa62zbFga9asKzhNPR1dneNzD69b0v O7lQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b6-v6si7719915plk.189.2018.03.08.03.02.52; Thu, 08 Mar 2018 03:03:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966281AbeCHLBC (ORCPT + 99 others); Thu, 8 Mar 2018 06:01:02 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:6183 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755802AbeCHK7r (ORCPT ); Thu, 8 Mar 2018 05:59:47 -0500 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 0758BD804C756; Thu, 8 Mar 2018 18:59:31 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.361.1; Thu, 8 Mar 2018 18:59:25 +0800 From: John Garry To: , , , , , , , , , CC: , , , , "John Garry" Subject: [PATCH v3 04/11] perf vendor events: add support for pmu events vendor subdirectory Date: Thu, 8 Mar 2018 18:58:29 +0800 Message-ID: <1520506716-197429-5-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1520506716-197429-1-git-send-email-john.garry@huawei.com> References: <1520506716-197429-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For some architectures (like arm), it is required to support a vendor subdirectory and not locate all the JSONs for a specific vendor in the same folder. This is because all the events for the same vendor will be placed in the same pmu events table, which may cause conflict. This conflict would be in the instance that a vendor's custom implemented events do have the same meaning on different platforms, so events in the pmu table would conflict. In addition, per list command may show events which are not even supported for a given platform. This patch adds support for a arch/vendor/platform directory hierarchy, while maintaining backwards-compatibility for existing arch/platform structure. In this, each platform would always have its own pmu events table. In generated file pmu_events.c, each platform table name is in the format pme{_vendor}_platform, like this: struct pmu_events_map pmu_events_map[] = { { .cpuid = "0x00000000420f5160", .version = "v1", .type = "core", .table = pme_cavium_thunderx2 }, { .cpuid = 0, .version = 0, .type = 0, .table = 0, }, }; Signed-off-by: John Garry Acked-by: Jiri Olsa --- tools/perf/pmu-events/README | 4 +++ tools/perf/pmu-events/jevents.c | 64 +++++++++++++++++++++++++++++++++++++---- 2 files changed, 62 insertions(+), 6 deletions(-) diff --git a/tools/perf/pmu-events/README b/tools/perf/pmu-events/README index 2407abc..655286f 100644 --- a/tools/perf/pmu-events/README +++ b/tools/perf/pmu-events/README @@ -28,6 +28,10 @@ sub directory. Thus for the Silvermont X86 CPU: Cache.json Memory.json Virtual-Memory.json Frontend.json Pipeline.json +The JSONs folder for a CPU model/family may be placed in the root arch +folder, or may be placed in a vendor sub-folder under the arch folder +for instances where the arch and vendor are not the same. + Using the JSON files and the mapfile, 'jevents' generates the C source file, 'pmu-events.c', which encodes the two sets of tables: diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c index 1d02faf..7b9e210 100644 --- a/tools/perf/pmu-events/jevents.c +++ b/tools/perf/pmu-events/jevents.c @@ -572,7 +572,7 @@ static char *file_name_to_table_name(char *fname) * Derive rest of table name from basename of the JSON file, * replacing hyphens and stripping out .json suffix. */ - n = asprintf(&tblname, "pme_%s", basename(fname)); + n = asprintf(&tblname, "pme_%s", fname); if (n < 0) { pr_info("%s: asprintf() error %s for file %s\n", prog, strerror(errno), fname); @@ -582,7 +582,7 @@ static char *file_name_to_table_name(char *fname) for (i = 0; i < strlen(tblname); i++) { c = tblname[i]; - if (c == '-') + if (c == '-' || c == '/') tblname[i] = '_'; else if (c == '.') { tblname[i] = '\0'; @@ -739,25 +739,77 @@ static int get_maxfds(void) static FILE *eventsfp; static char *mapfile; +static int is_leaf_dir(const char *fpath) +{ + DIR *d; + struct dirent *dir; + int res = 1; + + d = opendir(fpath); + if (!d) + return 0; + + while ((dir = readdir(d)) != NULL) { + if (dir->d_type == DT_DIR && dir->d_name[0] != '.') { + res = 0; + break; + } else if (dir->d_type == DT_UNKNOWN) { + char path[PATH_MAX]; + struct stat st; + + sprintf(path, "%s/%s", fpath, dir->d_name); + if (stat(path, &st)) + break; + + if (S_ISDIR(st.st_mode)) { + res = 0; + break; + } + } + } + + closedir(d); + + return res; +} + static int process_one_file(const char *fpath, const struct stat *sb, int typeflag, struct FTW *ftwbuf) { - char *tblname, *bname = (char *) fpath + ftwbuf->base; + char *tblname, *bname; int is_dir = typeflag == FTW_D; int is_file = typeflag == FTW_F; int level = ftwbuf->level; int err = 0; + if (level == 2 && is_dir) { + /* + * For level 2 directory, bname will include parent name, + * like vendor/platform. So search back from platform dir + * to find this. + */ + bname = (char *) fpath + ftwbuf->base - 2; + for (;;) { + if (*bname == '/') + break; + bname--; + } + bname++; + } else + bname = (char *) fpath + ftwbuf->base; + pr_debug("%s %d %7jd %-20s %s\n", is_file ? "f" : is_dir ? "d" : "x", level, sb->st_size, bname, fpath); - /* base dir */ - if (level == 0) + /* base dir or too deep */ + if (level == 0 || level > 3) return 0; + /* model directory, reset topic */ - if (level == 1 && is_dir) { + if ((level == 1 && is_dir && is_leaf_dir(fpath)) || + (level == 2 && is_dir)) { if (close_table) print_events_table_suffix(eventsfp); -- 1.9.1