On 7/14/01 1:02 AM, Jason R Thorpe at thorpej@zembu.com wrote:

> This method is a whole lot simpler, eliminates the need to deal with
> other processors, and may in fact reduce the amount of overhead involved
> for processes that do in fact use FP.

So, instead of taking 44371 FEN traps and doing 44371 save/restore FP state
trips across potentially two processors, you're now going to do an unknown
number (as few as 44371 or as many as 93470, but the exact number wasn't
measured) of save/restore FP state trips.

This sounds like it might very well be a performance win, and it certainly
wins on simplicity (which is probably enough on its own).  To determine
whether it'd be a performance win, we still need three more pieces of data:
how many of those context switches would involve saving and restoring FP
state, and how long it takes to save/restore and to trap/save/restore.  If
save/restore takes less than half the time to trap/save/restore (which is
very likely, especially since the latter save could involve another CPU),
then this seems like it must be a performance win.

I wonder whether the roughly-half of the context switches that didn't
involve an FEN trap were cases where FP-using processes didn't use FP during
that round of execution, or whether that portion was accounted for largely
by non-FP-using processes.

I'm not trying to diminish the work you've done, here, of course!  This is
great stuff!  Just trying to further the discussion...

- Geoff