Re: Per-CPU Unit (PCU) interface

[Martin Husemann <martin%duskware.de@localhost>]

On Mon, Jan 24, 2011 at 03:27:58PM +0000, Mindaugas Rasiukevicius wrote:
> While looking at the bugs on still work-in-progress mips64 FPU code on
> Matt's branch, it occurred to me that we could abstract SMP handling
> complexity into MI interface.  Basically, all architectures are using
> similar logic for FPU handling on SMP, but each have own variations,
> confusions, and therefore each fall into the bugs.  Hence, PCU:

I can't make up my mind if this is a complication or proper abstraction.

Assuming it is only used for lazy FPU saving and an arch does not have
other PCU needs, it overall does not save a lot of work. On the other
hand it does not allow MD optimiziations (obvious example are the fpu
handling IPIs on sparc64 where we do not bother to create a full C runtime
environment in the IPI handler).

> - There can be multiple PCUs, so this can be re-used not only for FPU,
> but any similar MD functionality, e.g. PowerPC AltiVec.

Are there other examples of this?

> - Once there is MI IPI support, it is ~trivial to convert the code to
> use them by: 1) splsoftclock() -> splhigh() 2) replacing xc_unicast()
> calls with cpu_send_ipi() and moving them *before* splx().

I can not parse this paragraph - and what "MI IPI support" are you talking
about? How does it differ form xcall(9)?

Martin