[GSoc] Timeconter Performance Improvements

[Warner Losh]

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 at 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.
>> 
>> 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?
> 
> I think we should just fallback to a syscall in that case.  We will also need 
> to do that if the TSC is not used as the timecounter (or always duplicate the 
> 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 
> good first milestone.  Once that is in place we can decide what the value is 
> 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 
> approach is more complex, but it makes the ABI boundary between userland and 
> the kernel more friendly to future changes.  I believe Linux does the latter 
> 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