Date: Fri, 27 Mar 2009 18:25:14 +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.0903271824170.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.
One note though -- the time to do the global page is at execve()-time.
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.0903271824170.60642>