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 <j...@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_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
