Improving the kernel/i386 timecounter performance (GSoC proposal)

[David Xu]

Prashant Vaibhav wrote:
> ...and that is _exactly_ what I propose(d) in the beginning and what OSX
> already does. Further, keeping the shared page and functions fixed at the
> end of the memory space has advantages like not needing any special linking,
> being easily accessible for code jumps or data reads, and so on [1]. The TSC
> issues are but one part of the puzzle.
> After this week-long discussion I still can't decide whether this was
> something that's desirable at all: keeping in mind that it's among the few
> project ideas tagged as "Suggested for Google Summer of Code 2009" on the
> FreeBSD website.  :-\  Though I've been reading mailing list archives, and
> the various handbooks, I'm not familiar well enough with other parts of the
> freebsd kernel to draft another concrete proposal on my own at this time.
> 
> [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN
> 0321278542
> 
> 

Without using ELF, but using signal like trampoline code as we current 
do makes it very difficult for some language to do asynchronous stack
unwinding, e.g pthread async cancellation and C++ objection destruction.

See my recent work for pthread cancellation and stack unwinding:
http://people.freebsd.org/~davidxu/patch/unwind.patch

Check x86_64_fallback_frame_state() to see what hacking code should be 
written.

Regards,
David Xu