Date: Fri, 27 Mar 2009 18:23:57 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: Sergey Babkin <babkin@verizon.net>, freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <alpine.BSF.2.00.0903271821060.60642@fledge.watson.org> In-Reply-To: <49CD0405.1060704@samsco.org> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?alpine.BSF.2.00.0903271821060.60642>