From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 26 07:01:33 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AE716A418 for ; Sat, 26 Jan 2008 07:01:33 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8E313C455 for ; Sat, 26 Jan 2008 07:01:32 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1005065fgg.35 for ; Fri, 25 Jan 2008 23:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=neRUG3OtfZfOIUavZ4P8nh5KVwHzekeyeD7IOs1GbIw=; b=TpPTAsDb6xU8Nh1B+RRE7njs7UAlAe3sab0srBP3/3bv/akjJf9K6HTUoI0U3ivRTklLTra3I03O9P1YDRvxh49mafJ7Hqr9vhj8ampUbtEa2UcfSbkz5v4ZNd2d/ZFh4cpQL9Isvy8HzOOlWDhxvGwy/OA1vw+0uOx0kCpQi7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JjQfKG06NJY6buPhibply6yDxFk2optp+WBMGhVPxxufTPHnTZJanOItmxCES6aHw3PJjGg6qujxglO/vvY0KS08tfn2Kp6Z1++0Ke9oDYJe/oy10cqKl9o7P5njF39UF1BYk3FvTb+wGHF6RqjJ5AbUIQYLsx9lvVEUZoU9pF8= Received: by 10.86.97.7 with SMTP id u7mr2679210fgb.39.1201329267984; Fri, 25 Jan 2008 22:34:27 -0800 (PST) Received: by 10.86.90.11 with HTTP; Fri, 25 Jan 2008 22:34:27 -0800 (PST) Message-ID: <84dead720801252234v1e7a8856g339faa02c1250bbf@mail.gmail.com> Date: Sat, 26 Jan 2008 12:04:27 +0530 From: "Joseph Koshy" To: "Kris Kennaway" In-Reply-To: <47963911.4000002@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-hackers@freebsd.org, Stefan Lambrev Subject: Re: gettimeofday() in hping X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2008 07:01:33 -0000 > 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