From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 30 21:32:35 2009 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 3BB1410656FB; Mon, 30 Mar 2009 21:32:35 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id F23AB8FC28; Mon, 30 Mar 2009 21:32:34 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2423872wfg.7 for ; Mon, 30 Mar 2009 14:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CKInX/R8Ktd0f1VtjI5LVRsFmzGf/4qZhPlwTq++mx8=; b=LoqjF2GPCmpYx0CXp/da+6UZr8ZlIFUrwKEBl8YWShnqB8YAKMYfJ/r/aOzizhUHeh t7Vcd01fEDbxSHr8gHZvV0Vn7NSioE3myo99et5gdeoD85Uze9eVFMvGeXPnZLFkWAcg EmRw7+TDhAA5pxYvbW/1yPYMTOS529Qr+41nY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Uyq77qrWyhxSjfTakZB8MMYM/6ZDhyzgF3svEfKFvoq6SURi2O/dk/eMRbsJcEuyDc dyQcsazFEFIPPzFxRSgrfA+XG0CSuX/hCr65FZCDBjb4XRxePo0AVrTUOlGmsSl1synI 7KQSkPBv6y/0fa67Vg6SDCnaTO7PAlwOI/tag= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr2280257wfr.186.1238448754471; Mon, 30 Mar 2009 14:32:34 -0700 (PDT) In-Reply-To: <49D11D7F.2020503@freebsd.org> References: <9969.1238398362@critter.freebsd.dk> <49D11D7F.2020503@freebsd.org> Date: Tue, 31 Mar 2009 03:02:34 +0530 Message-ID: <17560ccf0903301432t6a94dd86tb2f2a1a8d6edd7c2@mail.gmail.com> From: Prashant Vaibhav To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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: Mon, 30 Mar 2009 21:32:37 -0000 ...and that is _exactly_ what I propose(d) in the beginning and what OSX already does. Further, keeping the shared page and functions fixed at the end of the memory space has advantages like not needing any special linking, being easily accessible for code jumps or data reads, and so on [1]. The TSC issues are but one part of the puzzle. After this week-long discussion I still can't decide whether this was something that's desirable at all: keeping in mind that it's among the few project ideas tagged as "Suggested for Google Summer of Code 2009" on the FreeBSD website. :-\ Though I've been reading mailing list archives, and the various handbooks, I'm not familiar well enough with other parts of the freebsd kernel to draft another concrete proposal on my own at this time. [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN 0321278542 On Tue, Mar 31, 2009 at 12:59 AM, Tim Kientzle wrote: > Poul-Henning Kamp wrote: > >> In message <20090329180745.GB38985@server.vk2pj.dyndns.org>, Peter Jeremy >> write >> s: >> >> I'm assuming folks are still in love with the TSC because it still the >>>> cheapest as oppose ACPI-fast or HPET to even contemplate this? >>>> >>> That is its major advantage. It might be feasible to export all the >>> data necessary to implement the complete CLOCK_*_FAST family. >>> >> >> The general attraction is that it can be read from userland by >> unpriviledged >> programs. >> >> On systems where the ACPI or HPET hardware can be memory-mapped, I should >> be equally possible to map those read-only into userland processes. >> >> Now _THAT_ would be interesting. >> > > Which brings us back to having a page of code > provided by the kernel so that the kernel can > determine the appropriate implementation > (depending on the hardware availability) and so > that userland can invoke the functions without > going through a task switch. Libc can then > either invoke these directly or, if the page is > unavailable for any reason, use the system calls. > > Tim > >