From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 20:48:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0488C106566B for ; Fri, 27 Mar 2009 20:48:43 +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 BF7AC8FC23 for ; Fri, 27 Mar 2009 20:48:42 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1350110wfg.7 for ; Fri, 27 Mar 2009 13:48:42 -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=fL9AxkY8S5tUPvYhzMMNqugYrdC9/MpDKZdk8VDTsuA=; b=l8gv7DO4FjObTIkXHFLeJ0wFeQ5GGEA2aiMK2g9tFJY4gHnizQVrlFil3m3tVEqF3g ikMm4OjTAGSfkBachHaGxmrJ500IAXetE6r7GWkv4FmGoJeiXhNf2cg+mTAbZ2KTTuTj M3MG7pAeoedN8bhylagwDJDkXQFhzgrqQrvVY= 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=m7oek8mIH8t+3Q4iLLLvXp6FQVXfQTmGykayXQnY6d3qTRaBhS0q9MOk8HAfJoSUqd Rra0CxS6c0SRU3TnM5cX3VvNlvozpz8OQbg8SFRtB7K2Tmft50uT1VPGl3FphoLKPLBA 2Tpk1eKVz+Ng/u0NV62pGwQr/+lBMAvkEvNUM= MIME-Version: 1.0 Received: by 10.142.79.17 with SMTP id c17mr1050527wfb.171.1238186922255; Fri, 27 Mar 2009 13:48:42 -0700 (PDT) In-Reply-To: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> Date: Sat, 28 Mar 2009 02:18:42 +0530 Message-ID: <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> From: Prashant Vaibhav To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:48:43 -0000 Actually OS X is more similar than that: the shared page also contains functions that can be called by user applications, though their entry points are fixed and they're not in any particular format like elf/mach-o. Userspace implementations of gettimeofday, bcopy etc. are provided in the kernel itself, which is a nice design imo as the specific version to load is chosen by the kernel at boot time depending on processor capabilities. On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson wrote: > > On Fri, 27 Mar 2009, Scott Long wrote: > > I've been talking about this for years. All I need is help with the VM >> magic to create the page on fork. I also want two pages, one global for >> gettimeofday (and any other global data we can think of) and one per-process >> for static data like getpid/getgid. >> > > FWIW, there are some variations in schemes across OS's -- one extreme is > the Linux approach, which actually exports a mini shared library in ELF > format on the shared page, providing implementations of various services > (such as entering system calls), time stuff, etc. Less extreme are the > shared pages offered on Mac OS X, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > >> Scott >> >> >> Sergey Babkin wrote: >> >>> (Sorry for the top quoting). Probably the best implementation of >>> gettimeofd=y() is to have >>> a page in the kernel mapped read-only to all the user pr=cesses. Put >>> the kernel's idea of time >>> into this page. Then getting the =ime becomes a simple read (OK, two >>> reads, to make sure that >>> no update =as happened in between). >>> The TSC can then be used to add the precis=on between the ticks of >>> the kernel timer: >>> i.e. remember the value of TS= when the last tick happen, and the >>> highest rate at which >>> TSC may be ti=king at this CPU, and export in the same page. This >>> would guarantee thatthe time is not moving back. >>> However there are more issues with TS=. TSC is guaranteed to have >>> the same value >>> on all the processors that s=are the same system bus. But if the >>> machine is built of multiple >>> buses =ith bridges between them, all bets are off. Each bus may be >>> stopped, resta=ted >>> and clocked separately. There is no way to tell, on which CPU is th= >>> process currently >>> runnning, and it may be rescheduled do a different C=U right before >>> or after the RDTSC >>> instruction. >>> -SB >>> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >>> In message <[2]17560ccf0903260551v1f5cba9eu8 >>> 7727c0bae7baa3@mail.gmail.com>, Prasha >>> nt Vaibhav writes: >>> =The gettimeofday() function's implementation will then be >>> >change= to read the timestamp counter (TSC) from the processor, >>> and use the >>> &g=;reading in conjunction with the timing info exported by the >>> kernel to >>> =calculate and return the time info in proper format. >>> I take it a= read, that you know that there are other relvant >>> functions than gettim=ofday() and that these must provide a >>> monotonic timescale when queried =nterleaved ? >>> Be aware that the TSC may not be, and may not stay syn=hronized >>> across multiple cores. >>> Further more, the TSC is not con=tant frequency and in particular >>> not "known frequency" at all times. >>> There are a lot of nasty cases to check, and a nasty interpolation >>> =equired, which, in my tests some years back, totally negated any >>> speedu= from using the TSC in the first place. >>> At the very minimum, you wi=l have to add a quirk table where >>> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >>> find them. >>> >This will also pave way f=r optionally making the >>> >FreeBSD kernel tickless, >>> Rubbish. T=mecounters are not even closely associated with the >>> tick or ticklessnes= of the kernel. [1] >>> > - The TSC frequency might change on cert=in processors with >>> non-constant >>> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >>> only way to >>> > combat this is that t=e kernel be notified every time the >>> processor >>> > frequency changes.=very cpu frequency driver will need to be >>> updated to >>> > notify the=ernel before and after a cpu freq change. >>> That is not good enough= the bios may autonomously change the cpu >>> speed >>> and the skew from not k=owing exactly _when_ and _how_ the cpu >>> clock >>> changed, is a significant =umber of microseconds, plenty of time >>> to make strange things happen. >>> You will want to study carefully Dave Mills work to tame the alpha >>> =hips wandering SAW clocks. >>> Poul-Henning >>> [1] In my mind, rewo=king the callout system in the kernel would >>> be a much better more neded=nd much more worthwhile project. >>> -- >>> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >>> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >>> FreeBSD committer | BSD since 4.3-tahoe >>> N=ver attribute to malice what can adequately be explained by >>> incompetence.<=r>_______________________________________________ >>> [4]freebsd-hackers@freebsd.org mailing list >>> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >>> unsubscribe, send any mail to "[6]fre >>> ebsd-hackers-unsubscribe@freebsd.org" >>> >>> References >>> >>> 1. 3D"mailto:phk@phk.freebsd.dk" >>> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >>> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >>> 6. 3D"mailto: >>> freebsd-hackers-unsub_______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >>