Sent from my iPhone

> On Dec 3, 2018, at 02:45, Nadav Har'El <[email protected]> wrote:
> 
> 
>> On Sun, Dec 2, 2018 at 11:26 PM Waldek Kozaczuk <[email protected]> wrote:
>> I think I have good news but I am adding my comments inlined.
> 
> This is excellent news!
> I think, then, we'll need to add FNINIT or maybe just FEMMS (see my last 
> comment in https://github.com/cloudius-systems/osv/issues/1019) to either the 
> FPU fpu_lock code, or to the context switch code. I think just the former 
> would be better, for several reasons:
I have not tested if former fixes anything. But I agree with you that it 
should. 
> 1. It will protect the kernel's FPU code, not just the other threads, from 
> starting with a filled stack.
> 2. A workload which does a lot of voluntary context switching will not suffer 
> any performance loss (interrupts are already slow). tests/misc-ctxsw should 
> not show any performance degredation, I think. In general OSv already 
> optimizes voluntary context switches more than involuntary ones (interrupts).
> 3. It will be enough to protect the switched-to thread because the kernel 
> will not leave anything in the stack (I think... because thread::switch_to() 
> is a function...
> 
> It will be nice to have a test for this. Perhaps, as I suggested earlier, one 
> thread in a busy loop filling the fpu stack, or doing sse (xmm) work, or both 
> (two test cases) and another thread in a busy loop doing normal floating 
> point work, and see if one bothers the other (or the kernel).
Any good examples off code using xmm can you point me to? Do you think I will 
have to code this in assembly ?
> 
>> 
>> And at least the issue described in #1010 went away based on around 30-40 
>> executions which used to fail almost every time. So I think is very good 
>> news !!!  
> 
> :-)
> 

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to