[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1112201040190.11369@cl320.eecs.utk.edu>
Date: Tue, 20 Dec 2011 10:48:26 -0500
From: Vince Weaver <vweaver1@...s.utk.edu>
To: Ingo Molnar <mingo@...e.hu>
CC: Avi Kivity <avi@...hat.com>,
Robert Richter <robert.richter@....com>,
Benjamin Block <bebl@...eta.org>,
Hans Rosenfeld <hans.rosenfeld@....com>, <hpa@...or.com>,
<tglx@...utronix.de>, <suresh.b.siddha@...el.com>,
<eranian@...gle.com>, <brgerst@...il.com>,
<Andreas.Herrmann3@....com>, <x86@...nel.org>,
<linux-kernel@...r.kernel.org>,
Benjamin Block <benjamin.block@....com>
Subject: Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)
On Tue, 20 Dec 2011, Ingo Molnar wrote:
> Granted, LWP was mis-designed to quite a degree, those AMD chip
> engineers should have talked to people who understand how modern
> PMU abstractions are added to the OS kernel properly.
You do realize that LWP was probably in design 5+ years ago, at a time
when most Linux kernel developers wanted nothing to do with perf counters,
and thus anyone they did contact for help would have been from the
since-rejected perfctr or perfmon2 camp.
Also, I'm sure Linux isn't the only Operating System that they had in mind
when designing this functionality.
Running LWP through the kernel is a foolish idea. Does anyone have any
numbers on what that would do to overhead?
perf_events creates huge overhead when doing self monitoring. For simple
self-monintoring counter reads it is an *order of magnitude* worse than
doing the same thing with perfctr.
(see numbers here if you don't believe me:
http://web.eecs.utk.edu/~vweaver1/projects/perf-events/benchmarks/rdtsc_overhead/ )
Vince
--
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