Re: Per-CPU Unit (PCU) interface

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> 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. <...>

Apart from fixing the bugs (which I have found even on x86 FPU handling,
which is probably most tested), it saves quite a bit, and is supposed to
be efficient (note that it handles kernel preemption, which e.g. sparc64
does not support yet).

> 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).

It seems to me like increased complexity, due to assembly, with very little
gain.  After all, sparc may stay with existing FPU code, if you prefer so.

> > - 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?

For most archs it would be only FPU, but latest ARM or PowerPC processors
have various SIMD extensions.  Perhaps Matt could tell more about them.

> > - 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)?

Currently, xcall(9) with XC_HIGHPRI will schedule a software interrupt on
the target CPU.  IPI is a "hard" interrupt, which is more lightweight and
suitable to use here.  However, we do not have MI interface to send them.
We ought to add it at some point.

Perhaps it confused you since IPIs (Inter-Processor Interrupts) on sparc
are called "xcalls"?

> 
> Martin

-- 
Mindaugas