[<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