Re: Improving the kernel/i386 timecounter performance (GSoC proposal)


On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:

In message <alpine.BSF.2.00.0903272254460.12518@xxxxxxxxxxxxxxxxx>, Robert Wats
on writes:

I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page.

Rule #3:
The only thing worse than generalizing from one example is
generalizing from no examples at all.

We can add those mappings when we know why we would want them.

If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. In which case user application threads will need to know their CPU in order to use the right conversion data (ideally without a system call, since that's part of what we're avoiding here), or use a per-CPU mapping and not know (in which case they'll need to detect and handle the very rare "preempted and migrated between read TSC and read conversion data" race). I'm not pushing a per-CPU page, but there would be some interesting advantages to supporting that.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... then there might be some interesting advantages to a per-CPU page. ... We can add those mappings when we know why we would want them. ... If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. ... In which case user application threads will need to know their CPU in order to use the right conversion data, or use a per-CPU mapping and not know. ...
    (freebsd-hackers)
  • Re: [GSoc] Timeconter Performance Improvements
    ... Synchronised P-state invariant TSCs vastly simplify the problem but ... support per-CPU TSC counts and varying frequencies or a fallback to ... non-synchronised TSCs, this would need to be changed to per-CPU. ...
    (freebsd-hackers)