Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Jan 2008 12:04:27 +0530
From:      "Joseph Koshy" <joseph.koshy@gmail.com>
To:        "Kris Kennaway" <kris@freebsd.org>
Cc:        =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-hackers@freebsd.org, Stefan Lambrev <stefan.lambrev@moneybookers.com>
Subject:   Re: gettimeofday() in hping
Message-ID:  <84dead720801252234v1e7a8856g339faa02c1250bbf@mail.gmail.com>
In-Reply-To: <47963911.4000002@FreeBSD.org>
References:  <4795CC13.7080601@moneybookers.com> <868x2i3v8d.fsf@ds4.des.no> <864pd63v2h.fsf@ds4.des.no> <4795FE54.9090606@moneybookers.com> <86lk6i0vzk.fsf@ds4.des.no> <479605E2.6070709@moneybookers.com> <479621BE.2060907@FreeBSD.org> <4796357B.9020508@moneybookers.com> <47963911.4000002@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>  OK, this is the famous problem with modern CPUs that jkoshy has declined
>  to work around :(  There are patches for this in perforce, see
>
>  http://perforce.freebsd.org/changeView.cgi?CH=126189

"Famous problem" indeed :).   I declined the patch because it
is incorrect and incomplete.

First, you cannot safely treat the Core and Core 2 PMCs as P6 PMCs.
Doing so would give userland a way to program CPU MSRs with bit
patterns that have been expressly documented by the manufacturer
as "reserved" and forbidden.

Second, the change ignores the sometimes changed semantics
between P6 and Core PMCs for events sharing the same numeric
selector value.  Not handling the changed semantics could easily
trip up users; they would think that they are measuring hardware
behaviour X while the measurements would actually be for behaviour Y.

Third, the change ignores the user interface.   libpmc's event
naming conventions are to follow vendor names for events and
event modifiers as closely as possible (within the constraints of
the overall generic syntax).  This is so as to make it easy (easier?)
for users to read vendor documentation and map the information
there to the necessary event selection syntax.

Core PMCs support tons of new measurement events.  Additionally,
naming conventions in vendor documentation for Core event names
and modifiers are different from the older P6 names, even for events
with similar semantics.  The submitted patch does not address these
aspects.


I will accept a patch that demonstrates clue about the
workings of the overall system---the changes in the patch
should be safe, complete, should demonstrate that the submitter
has read and understood vendor documentation, should preserve
user experience for naming events, and each supported PMC event
needs to be documented in pmc.3.

Regards,
Koshy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84dead720801252234v1e7a8856g339faa02c1250bbf>