[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160118180614.GV6357@twins.programming.kicks-ass.net>
Date:	Mon, 18 Jan 2016 19:06:14 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	acme@...nel.org, jolsa@...nel.org, eranian@...gle.com,
	linux-kernel@...r.kernel.org, mingo@...nel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 09/11] x86, perf: Support sysfs files depending on SMT
 status
On Fri, Jan 15, 2016 at 05:12:51PM -0800, Andi Kleen wrote:
> +ssize_t events_ht_sysfs_show(struct device *dev, struct device_attribute *attr,
> +			  char *page)
> +{
> +	struct perf_pmu_events_ht_attr *pmu_attr =
> +		container_of(attr, struct perf_pmu_events_ht_attr, attr);
> +
> +	/*
> +	 * Report conditional events depending on Hyper-Threading.
> +	 *
> +	 * This is overly conservative as usually the HT special
> +	 * handling is not needed if the other CPU thread is idle.
> +	 *
> +	 * Note this does not (cannot) handle the case when thread
> +	 * siblings are invisible, for example with virtualization
> +	 * if they are owned by some other guest.  The user tool
> +	 * has to re-read when a thread sibling gets onlined later.
> +	 */
> +
> +	return sprintf(page, "%s",
> +			x86_pmu.ht_on ?
> +			pmu_attr->event_str_ht :
> +			pmu_attr->event_str_noht);
> +}
So one obvious problem with this is that a concurrent hotplug operation
can toggle ht_on resulting in bogus measurements.
I'm not sure there's anything we can do about that, other than WARN in
the tool if it finds inconsistent results; does it?
Powered by blists - more mailing lists
 
