lwp handoff between CPUs

Normally, if a CPU decides to run a thread and that thread has previously run on a different CPU, it just grabs and executes it. If you have CPU-dependent state (lazy FP context), this can be a bad idea since it requires extra IPIs and synchronization.

Instead, I propose a standard IPI to request the that LWP be divorced from its last CPU. And until the divorce is complete, the lwp can not be married to a new cpu.

Killing ticks

NetBSD uses implements its clock via a clock interrupt that fires at a (mostly) constant rate, which was the way BSD 4.2 did it over 25 years ago. However, that implementation is showing its age due to the overhead of the clock timers, the coarseness of them, and their power unfriendliness.

This will require a change to the way callouts and other kernel timeouts are done. Instead of passing the number of ticks for the callout to fire, a hard deadline in the future represented in the opaque type of clock_deadline_t will be passed instead. This deadline is based on the monotonic clock kept by the kernel. There will be functions to convert timespecs and nanosecond unitized delays into clock_deadline_t. Other uses of ticks will need to be converted to use callouts such as quantum scheduling or sleep intervals.

The fallout of this is that the system now knows when the next timer needs to fire, which hopefully is more than a few ticks ahead in the future. The system can now pass that knowledge to the MD clock code so it can avoid scheduling premature clock timers. So whenever the deadline changes (either to a sooner or later value), the timeout code will call void cpu_set_deadline(clock_deadline_t). The MD code can use clock_deadline_to_ns(clock_deadline_t) to find when that deadline is and do the appropriate thing.

Additionally, hardclock needs to take an additional uint64_t argument which is the number of nanoseconds since the last call to hardclock.