[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ej0mx0c0.fsf@basil.nowhere.org>
Date: Fri, 05 Dec 2008 13:39:43 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: David Miller <davem@...emloft.net>, a.p.zijlstra@...llo.nl,
paulus@...ba.org, tglx@...utronix.de, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
eranian@...glemail.com, dada1@...mosbay.com,
robert.richter@....com, arjan@...radead.org, hpa@...or.com,
rostedt@...dmis.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux
Ingo Molnar <mingo@...e.hu> writes:
> Note that more notification record types is actually where latest
> hardware is going: for example in Nehalem there's a PEBS notification
> record type that has cachemiss latency included in the record. I.e. we
> can get profiles with _cachemiss latency_ included (as measured from
> issuing the instruction to completion).
One problem is that you have to find out the correct RIP for that PEBS
cache miss you have to disassemble from the last basic block because
the IP in PEBS points to the next instruction.
If such a thing is ever implemented it should be in user space
I think.
Also in general some of the more useful PEBS information requires
disassembling unfortunately. For example if you want a address
histogram you get the register contents, but you have to interpret the
code to compute the EA. While the kernel has a x86 interpreter now for
this I suspect doing it in kernel space would be quite complicated
and at least I would consider doing it in user space cleaner too.
Given these are more obscure features, but not being able to fit
them easily into your model from the start isn't a very promising sign
for the long term extensibility of the design.
-Andi
--
ak@...ux.intel.com
--
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