From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 28 02:23:21 2011 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 B4C3A106566C for ; Mon, 28 Mar 2011 02:23:21 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FEBE8FC13 for ; Mon, 28 Mar 2011 02:23:21 +0000 (UTC) Received: by iwn33 with SMTP id 33so3882100iwn.13 for ; Sun, 27 Mar 2011 19:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jl5pBHzXzKSxxkOd8uSr9K1QF2E0eBMyhHzsv1aIN7I=; b=BjA6v/ImD+joAhQsZO1Z2h4tpK/e8VFi/e/G271+dNf+OGA0gnsuaLmOdsXnEwcwa/ TvrNN6NMua5wwVBenLuA4inpfG1louNKWoWuoEviaF9+ClDShwRp/lDi6wdqlDcXZD2+ vfvz6xUanuOsdWsJGZDEXV5/BJKEkc8+nCvtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xfr0bjYhllXPMpf3SryPe3M/k7BBoM9Xe9cZL97HOipWPzZOWma0xL9AK2JDmvsRaE 0dSK2cb9ZOU1k/MOysFKZohQ8IGqhqDUYNyBOIgclgLgXwe9qBPSynR3W1FydUEu1umo RIlH81bQHRv0A+nJEGfyb0T9I55g2LIYDqaCU= Received: by 10.42.130.130 with SMTP id v2mr6195072ics.233.1301278999795; Sun, 27 Mar 2011 19:23:19 -0700 (PDT) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id o3sm2605646ibd.10.2011.03.27.19.23.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2011 19:23:18 -0700 (PDT) Message-ID: <4D8FF114.9080300@gmail.com> Date: Sun, 27 Mar 2011 21:23:16 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Warner Losh References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.com> In-Reply-To: <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: kostikbel@gmail.com, freebsd-hackers@FreeBSD.org, John Baldwin , Jing Huang Subject: Re: [GSoc] Timeconter Performance Improvements 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, 28 Mar 2011 02:23:21 -0000 On 3/27/2011 5:32 PM, Warner Losh wrote: > On Mar 26, 2011, at 8:43 AM, Jing Huang wrote: > >> Hi, >> >> Thanks for you all sincerely. Under your guidance, I read the >> specification of TSC in Intel Manual and learned the hardware feature >> of TSC: >> >> Processor families increment the time-stamp counter differently: >> • For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4 >> processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]); >> and for P6 family processors: the time-stamp counter increments with every >> internal processor clock cycle. >> >> • For Pentium 4 processors, Intel Xeon processors (family [0FH], >> models [03H and >> higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model >> [0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors >> (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family >> [06H], display_model [17H]); for Intel Atom processors (family [06H], >> display_model [1CH]): the time-stamp counter increments at a constant rate. >> >> Maybe we would implement gettimeofday as fellows. Firstly, use cpuid >> to find the family and models of current CPU. If the CPU support >> constant TSC, we look up the shared page and calculate the precise >> time in usermode. If the platform has invariant TSCs, and we just >> fallback to a syscall. So, I think a single global shared page maybe >> proper. > I think that the userspace portion should be more like: > > int kernel_time_type) SECTION(shared); > struct tsc_goo tsc_time_data SECTION(shared); > > switch (kernel_time_type) { > case 1: > /* code to use tsc_time_data to return time */ > break; > default: > /* call the kernel */ > } > > I think we should avoid hard-coding lists of CPU families in userland. The kernel init routines will decide, based on the CPU type and other stuff if this optimization can be done. This would allow the kernel to update to support new CPU types without needing to churn libc. > > Warner > > P.S. The SECTION(shared) notation above just means that the variables are in the shared page. > >> >> On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin wrote: >>> On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: >>>> On 2011-Mar-25 08:18:38 -0400, John Baldwin wrote: >>>>> For modern Intel CPUs you can just assume that the TSCs are in sync across >>>>> packages. They also have invariant TSC's meaning that the frequency >>>>> doesn't change. >>>> Synchronised P-state invariant TSCs vastly simplify the problem but >>>> not everyone has them. Should the fallback be more complexity to >>>> support per-CPU TSC counts and varying frequencies or a fallback to >>>> reading the time via a syscall? >>> I think we should just fallback to a syscall in that case. We will also need >>> to do that if the TSC is not used as the timecounter (or always duplicate the >>> ntp_adjtime() work we do for the current timecounter for the TSC timecounter). >>> >>> Doing this easy case may give us the most bang for the buck, and it is also a >>> good first milestone. Once that is in place we can decide what the value is >>> in extending it to support harder variations. >>> >>> One thing we do need to think about is if the shared page should just export a >>> fixed set of global data, or if it should export routines. The latter >>> approach is more complex, but it makes the ABI boundary between userland and >>> the kernel more friendly to future changes. I believe Linux does the latter >>> approach? >>> >>> -- >>> John Baldwin >>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > If a user process can perform a rfork(2) or rfork_thread(3) with RFMEM option, then can't the same page table be active on multiple processors? Mapping per CPU page(s) to a fixed user addess(es) would only hold the last switched cpu's information. x86 architectures use a segment pointer to keep the kernel per cpu information current. --Mark Tinguely.