linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: kan.liang@intel.com
Cc: jolsa@kernel.org, a.p.zijlstra@chello.nl, luto@kernel.org,
	mingo@redhat.com, eranian@google.com, ak@linux.intel.com,
	mark.rutland@arm.com, adrian.hunter@intel.com,
	namhyung@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V9 1/6] perf,tools: introduce generic FEAT for CPU attributes
Date: Thu, 10 Sep 2015 10:58:38 -0300	[thread overview]
Message-ID: <20150910135838.GX3475@kernel.org> (raw)
In-Reply-To: <1441740769-61236-2-git-send-email-kan.liang@intel.com>

Em Tue, Sep 08, 2015 at 03:32:44PM -0400, kan.liang@intel.com escreveu:
> From: Kan Liang <kan.liang@intel.com>
> 
> This patch introduces generic FEAT for CPU attributes. For the patch
> set, we only need cpu max frequency. But it can be easily extented to
> support more other CPU attributes.
> The cpu max frequency is from the first online cpu.

Ok, but don't we have to do error handling? i.e. you are returning 0 for
any error in trying to read the cpu max freq, shouldn't we bail out
somewhere?

And please move this get_cpu_max_freq() thing out of the cpumap.[ch]
files, it is not even a need completely specific to perf tooling, there
must be somewhere in tools/lib/api/ (kernel APIs) where this fits, no?

More comments below.

- Arnaldo
 
> Signed-off-by: Kan Liang <kan.liang@intel.com>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  tools/perf/util/cpumap.c | 32 ++++++++++++++++++++++++++
>  tools/perf/util/cpumap.h |  1 +
>  tools/perf/util/header.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
>  tools/perf/util/header.h | 12 ++++++++++
>  4 files changed, 104 insertions(+)
> 
> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
> index a05d76a..671ee83 100644
> --- a/tools/perf/util/cpumap.c
> +++ b/tools/perf/util/cpumap.c
> @@ -514,3 +514,35 @@ int cpu__setup_cpunode_map(void)
>  	closedir(dir1);
>  	return 0;
>  }
> +
> +u64 get_cpu_max_freq(void)
> +{
> +	const char *mnt;
> +	char path[PATH_MAX], tmp;
> +	FILE *fp;
> +	u64 freq;
> +	int cpu = 0;
> +	int ret;
> +
> +	mnt = sysfs__mountpoint();
> +	if (!mnt)
> +		return 0;

See? Can't find the sysfs mount point? No problem, return 0 max freq.

> +
> +	snprintf(path, PATH_MAX, "%s/devices/system/cpu/online", mnt);
> +	fp = fopen(path, "r");
> +	if (fp) {
> +		ret = fscanf(fp, "%u%c", &cpu, &tmp);
> +		fclose(fp);
> +		if (ret < 1)
> +			return 0;

Can't parse it? 0

> +	}
> +
> +	snprintf(path, PATH_MAX, "%s/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq", mnt, cpu);
> +	fp = fopen(path, "r");
> +	if (!fp)
> +		return 0;

Ditto. Return soem error here please.

> +	ret = fscanf(fp, "%lu", &freq);
> +	fclose(fp);
> +
> +	return (ret == 1) ? freq : 0;
> +}
> diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
> index 8982d53..06cd2c4 100644
> --- a/tools/perf/util/cpumap.h
> +++ b/tools/perf/util/cpumap.h
> @@ -60,6 +60,7 @@ int max_node_num;
>  int *cpunode_map;
>  
>  int cpu__setup_cpunode_map(void);
> +u64 get_cpu_max_freq(void);

>  
>  static inline int cpu__max_node(void)
>  {
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 8fd7b7d..3535dcb 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -885,6 +885,23 @@ write_it:
>  	return do_write_string(fd, buffer);
>  }
>  
> +static int write_cpu_attributes(int fd, struct perf_header *h __maybe_unused,
> +				struct perf_evlist *evlist __maybe_unused)
> +{
> +	u32 tag_id;
> +	u64 max_freq;
> +	int ret;
> +
> +	tag_id = PERF_HEADER_CPU_MAX_FREQ;
> +	ret = do_write(fd, &tag_id, sizeof(tag_id));
> +	if (ret < 0)
> +		return ret;
> +
> +	max_freq = get_cpu_max_freq();

Here, do the error handling, return whatever errno code this function
returned, probably the feature code will use it to warn the user
somehow.

> +
> +	return do_write(fd, &max_freq, sizeof(max_freq));
> +}
> +
>  static int write_branch_stack(int fd __maybe_unused,
>  			      struct perf_header *h __maybe_unused,
>  		       struct perf_evlist *evlist __maybe_unused)
> @@ -1185,6 +1202,11 @@ static void print_cpuid(struct perf_header *ph, int fd __maybe_unused, FILE *fp)
>  	fprintf(fp, "# cpuid : %s\n", ph->env.cpuid);
>  }
>  
> +static void print_cpu_attributes(struct perf_header *ph, int fd __maybe_unused, FILE *fp)
> +{
> +	fprintf(fp, "# CPU attributes: max frequency = %lu KHz\n", ph->env.cpuattr.max_freq);
> +}
> +
>  static void print_branch_stack(struct perf_header *ph __maybe_unused,
>  			       int fd __maybe_unused, FILE *fp)
>  {
> @@ -1498,6 +1520,42 @@ static int process_cpuid(struct perf_file_section *section __maybe_unused,
>  	return ph->env.cpuid ? 0 : -ENOMEM;
>  }
>  
> +static int process_cpu_attributes(struct perf_file_section *section __maybe_unused,
> +				  struct perf_header *ph, int fd,
> +				  void *data __maybe_unused)
> +{
> +	ssize_t ret;
> +	u32 i, tag_id;
> +	u64 nr;
> +
> +	for (i = 0; i < PERF_HEADER_CPU_ATTR_MAX; i++) {
> +
> +		ret = readn(fd, &tag_id, sizeof(tag_id));
> +		if (ret != sizeof(tag_id))
> +			return -1;

Return some sensible errno... Its not because
perf_header__process_sections() doesn't check them that we shouldn't
return ;-\ I'll fix perf_header__process_sections() to stop the process
and warn the user if some error happens...

> +
> +		if (ph->needs_swap)
> +			nr = bswap_32(tag_id);
> +
> +		if (tag_id >= PERF_HEADER_CPU_ATTR_MAX) {
> +			pr_debug("The number of cpu attributes is not expected. "
> +				 "You may need to upgrade the perf tool.\n");
> +			return -1;


ditto
> +		}
> +
> +		ret = readn(fd, &nr, sizeof(nr));
> +		if (ret != sizeof(nr))
> +			return -1;


ditto

> +
> +		if (ph->needs_swap)
> +			nr = bswap_64(nr);
> +
> +		ph->env.cpu_attr[tag_id] = nr;
> +	}
> +
> +	return 0;
> +}
> +
>  static int process_total_mem(struct perf_file_section *section __maybe_unused,
>  			     struct perf_header *ph, int fd,
>  			     void *data __maybe_unused)
> @@ -1983,6 +2041,7 @@ static const struct feature_ops feat_ops[HEADER_LAST_FEATURE] = {
>  	FEAT_OPP(HEADER_PMU_MAPPINGS,	pmu_mappings),
>  	FEAT_OPP(HEADER_GROUP_DESC,	group_desc),
>  	FEAT_OPP(HEADER_AUXTRACE,	auxtrace),
> +	FEAT_OPP(HEADER_CPU_ATTR,	cpu_attributes),
>  };
>  
>  struct header_print_data {
> diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
> index 975d803..dd9f6b0 100644
> --- a/tools/perf/util/header.h
> +++ b/tools/perf/util/header.h
> @@ -31,6 +31,7 @@ enum {
>  	HEADER_PMU_MAPPINGS,
>  	HEADER_GROUP_DESC,
>  	HEADER_AUXTRACE,
> +	HEADER_CPU_ATTR,
>  	HEADER_LAST_FEATURE,
>  	HEADER_FEAT_BITS	= 256,
>  };
> @@ -71,6 +72,11 @@ struct cpu_topology_map {
>  	int	core_id;
>  };
>  
> +enum perf_header_cpu_attr {
> +	PERF_HEADER_CPU_MAX_FREQ	= 0,
> +	PERF_HEADER_CPU_ATTR_MAX,
> +};
> +
>  struct perf_env {
>  	char			*hostname;
>  	char			*os_release;
> @@ -95,6 +101,12 @@ struct perf_env {
>  	char			*numa_nodes;
>  	char			*pmu_mappings;
>  	struct cpu_topology_map	*cpu;
> +	union  {
> +		u64		cpu_attr[PERF_HEADER_CPU_ATTR_MAX];
> +		struct {
> +			u64	max_freq;
> +		} cpuattr;
> +	};

Ok, these need moving to env.h, but lets first get that patchkit
merged... Looking at your other patches

>  };
>  
>  struct perf_header {
> -- 
> 1.8.3.1

  reply	other threads:[~2015-09-10 13:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 19:32 [PATCH V9 0/6] Freq/CPU%/CORE_BUSY% support kan.liang
2015-09-08 19:32 ` [PATCH V9 1/6] perf,tools: introduce generic FEAT for CPU attributes kan.liang
2015-09-10 13:58   ` Arnaldo Carvalho de Melo [this message]
2015-09-10 15:35     ` Arnaldo Carvalho de Melo
2015-09-10 20:50       ` Liang, Kan
2015-09-08 19:32 ` [PATCH V9 2/6] perf,tools: read msr pmu type from header kan.liang
2015-09-10 13:59   ` Arnaldo Carvalho de Melo
2015-09-14 21:16   ` Arnaldo Carvalho de Melo
2015-09-08 19:32 ` [PATCH V9 3/6] perf, record: introduce --freq-perf option kan.liang
2015-09-09 14:34   ` Jiri Olsa
2015-09-14 21:14   ` Arnaldo Carvalho de Melo
2015-09-08 19:32 ` [PATCH V9 4/6] perf,tools: Dump per-sample freq/CPU%/CORE_BUSY% in report -D kan.liang
2015-09-10 14:21   ` Arnaldo Carvalho de Melo
2015-09-08 19:32 ` [PATCH V9 5/6] perf,tools: caculate and save freq/CPU%/CORE_BUSY% in he_stat kan.liang
2015-09-08 19:32 ` [PATCH V9 6/6] perf,tools: Show freq/CPU%/CORE_BUSY% in perf report by --freq-perf kan.liang
2015-09-09 14:36   ` Jiri Olsa
2015-09-09 14:39 ` [PATCH V9 0/6] Freq/CPU%/CORE_BUSY% support Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150910135838.GX3475@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).