Date: Sat, 26 Mar 2011 12:02:37 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, Jing Huang <jing.huang.pku@gmail.com> Subject: Re: [GSoc] Timeconter Performance Improvements Message-ID: <FEA1B2D9-C5B6-405D-889A-43EB78338527@bsdimp.com> In-Reply-To: <201103261012.32884.jhb@freebsd.org> References: <AANLkTimbBohQmoPv19Qq2U6M70OBx%2BFBMiUAzQmqrTLK@mail.gmail.com> <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 26, 2011, at 8:12 AM, 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 <jhb@freebsd.org> 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. >>=20 >> 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? >=20 > I think we should just fallback to a syscall in that case. We will = also need=20 > to do that if the TSC is not used as the timecounter (or always = duplicate the=20 > ntp_adjtime() work we do for the current timecounter for the TSC = timecounter). Logically, the code should look like: if (can_do_fast_time) do_the_fast_time else call the kernel We can expand what can or can't do the fast time later once we get the = basics working. > Doing this easy case may give us the most bang for the buck, and it is = also a=20 > good first milestone. Once that is in place we can decide what the = value is=20 > in extending it to support harder variations. Agreed. > 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=20= > approach is more complex, but it makes the ABI boundary between = userland and=20 > the kernel more friendly to future changes. I believe Linux does the = latter=20 > approach? There's nothing that says we can't couple this with loading a = cpu-specific shared library, which would also insulate things. Having a single page of both data and code strikes me as unwise. Having = one of each wouldn't be too bad. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FEA1B2D9-C5B6-405D-889A-43EB78338527>