Date: Fri, 24 Mar 2017 09:44:43 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Kan Liang <kan.liang@intel.com>
cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
        linux-kernel@vger.kernel.org, eranian@google.com, jolsa@kernel.org,
        ak@linux.intel.com
Subject: Re: [PATCH 0/3]measure SMI cost
In-Reply-To: <1490293551-5552-1-git-send-email-kan.liang@intel.com>
Message-ID: <alpine.DEB.2.20.1703240942590.3688@nanos>
References: <1490293551-5552-1-git-send-email-kan.liang@intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 942
Lines: 25

On Thu, 23 Mar 2017, kan.liang@intel.com wrote:

> From: Kan Liang <Kan.liang@intel.com>
> 
> Currently, there is no way to measure the time cost in System management
> mode (SMM) by perf.
> 
> Intel perfmon supports FREEZE_WHILE_SMM bit in IA32_DEBUGCTL. Once it sets,
> the PMU core counters will freeze on SMI handler. But it will not have an
> effect on free running counters. E.g. APERF counter.
> The cost of SMI can be measured by (aperf - cycles).
> 
> A new sysfs entry /sys/device/cpu/freeze_on_smi is introduced to set
> FREEZE_WHILE_SMM bit in IA32_DEBUGCTL.
> 
> A new --smi-cost mode in perf stat is implemented to measure the SMI cost
> by calculating cycles and aperf results. In practice, the percentages of
> SMI cycles should be more useful than absolute value.

That's only true for performance oriented analysis, but for analyzing the
root cause of latencies the actual cycles are definitely interesting.

Thanks,

	tglx