Date: Sat, 28 Mar 2009 02:18:42 +0530 From: Prashant Vaibhav <prashant.vaibhav@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <17560ccf0903271348p52351481v4cc83c14037e8836@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0903271821060.60642@fledge.watson.org> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <alpine.BSF.2.00.0903271821060.60642@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rwatson@freebsd.org> 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
>> "
>>
>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17560ccf0903271348p52351481v4cc83c14037e8836>