[coyotos-dev] Optional floating state

[David Hopwood]

Norman Hardy wrote:
> On Jan 25, 2006, at 1:05 PM, Sandro Magi wrote:
> 
>> This sounds interesting. The proposal:
>>
>> 1. reduces the IPC cost (potentially less context to save/restore)
>>
>> 2. reduces memory pressure (fewer objects need be resident when a 
>> domain is running)
>>
>> 3. penalizes domains that utilize the FPU/vector registers (an  extra
>> user-supervisor transition, and potential cache misses to the 
>> prepared states to restore the missing context every time the  domain
>> is set running and accesses the missing context -- or does  the lazy
>> load only occur if the domain's extra context isn't  already prepared?)
>>
>> It's not entirely clear that the overall result is faster; depends  on
>> how much this extra context is used on a given system.
>>
> Yes and no. Mostly no perhaps.
> Consider a domain X using floating point heavily.
> X calls another domain Y from time to time that has floating state  but
> is not using it.
> I this scenario the floating state of X remains in the floating 
> registers thru these calls.
> The gate path thru the kernel does not even have any conditional 
> transfers concerning floating point.
> The DIB for X has a control register value that is loaded upon  starting X.
> (DIB is explained at <http://cap-lore.com/CapTheory/KK/Kernel/ ADom.html>)
> That value has a bit allowing X to access its state in the real 
> floating registers.
> The control register value for Y disallows such access.
> These control register values in the respective DIBs are constant  thru
> out this scenario.
> This is a big win.
> 
> When both domains are using floating point on each turn then there are
> twice as many kernel entries.

I don't see why there have to be twice as many kernel entries. Just use
the heuristic that if a domain used FP (or vector) registers on its last
execution between context switches, it probably will on its current execution.
This loses the advantage of not having conditional transfers concerning FP
in the gate path, but it retains the other advantages. The accuracy of this
heuristic should be measured, but I suspect it is accurate enough to avoid
incurring any significant performance penalty.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>