[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150506155338.GF22949@pd.tnic>
Date: Wed, 6 May 2015 17:53:38 +0200
From: Borislav Petkov <bp@...en8.de>
To: Ingo Molnar <mingo@...nel.org>,
Andy Lutomirski <luto@...capital.net>
Cc: Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 207/208] x86/fpu: Add FPU performance measurement
subsystem
On Wed, May 06, 2015 at 06:52:39AM +0200, Ingo Molnar wrote:
> > Can you change "cycles" to "TSC ticks"? They're not quite the same thing.
>
> Yeah, with constant TSC we have the magic TSC frequency that is used
> by RDTSC.
>
> I'm torn: 'TSC ticks' will mean very little to most people reading
> that output. We could convert it to nsecs with a little bit of
> calibration - but that makes it depend on small differences in CPU
> model frequencies, while the (cached) cycle costs are typically
> constant per microarchitecture.
I think the best we should do is convert the TSC ticks to the unboosted
P0 frequency, i.e. if the P0 freq is say, 4GHz, we have 4*10^9 core
cycles per second. And then convert the counted TSC ticks to those
cycles.
For that we would need to measure in the beginning how TSC ticks relate
to P0 cycles and then use that number for conversion...
Hmmm.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists