Re: Per-CPU Unit (PCU) interface

[Andrew Doran <ad%netbsd.org@localhost>]

On Tue, Jan 25, 2011 at 10:10:14AM +0100, Martin Husemann wrote:
> 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).

I can't speak for Mindaugas but I suspect that one of the reasons for
centralising is that this sort of stuff is difficult to get right.

I don't buy into the microoptimization aspect so much because simply by
chosing to do an IPI we're already sucking rocks.  As long as the IPI
doesn't go mucking around with too much state that it wouldn't as an
assembly stub then in relative terms I don't see too much loss.
So I understand the concern and share it but I have trouble writing off
the MI idea on that alone.

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