Re: [Syllable-kernel] Patch: Updated atomic primitives

[Kristian V. D. V. <va...@li...>]

On Saturday 23 October 2004 9:03 pm, Jake Hamby wrote:
> Kristian Van Der Vliet wrote:
> > I may still accept these atomic patches as it's probably a good idea to
> > move away from direct access of atomic_t types as the kernel and drivers
> > do now, and I see no harm in moving to a more Linux-centric way of doing
> > things.  It will make drivers easier to port at least.  But sadly it does
> > not fix the immediate problem of SMP crashes.
> >
> > Back to scratching our heads it seems.
>
> What's the status on importing my patches for the atomic primitives? 

I'll get on with checking them in.  Hopefully they'll be in CVS today; I'll 
let you know as soon as I'm done.

> Anyway, I'm still looking at the SMP code.  Can you give me a better
> idea of how things are failing when compiled with -O3?  So far, the only
> real error message I got was from the original poster, William Rose, a
> "Divide error" when opening Terminal.  What are the other symptoms?

I'll capture a few kernel logs from both an -O3 and -O2 kernel; the symptoms 
appear to be identical.

> * Inlining a number of assembly routines from intel.s, such as
> cli()/sti(), get/put_cpu_flags(), isa_read*(), isa_write*(),
> flush_tlb(), save/load_fpu_state(), etc.

Sounds sensible.

> * Implement lazy FP context switching.  Instead of spending the time to
> save and restore the FPU state on every context switch, a flag can be
> set to throw an exception the next time the FPU is used.  For threads
> that never touch the FPU, nothing has to be saved, and when a thread
> accesses the FPU, the exception handler saves the FPU state for the last
> thread that was using it, then restores the FPU state for the current
> thread.  If the current thread is also the last thread that was using
> the FPU, then nothing has to be saved and the FPU is simply enabled.

Sounds like a great idea to me.  Anything that can save a few ticks on a 
context switch it always a good idea :)

> This goes hand-in-hand with my plan to extend save_fpu_state() to use
> FXSAVE instead of FSAVE on Pentium III and above (including Athlon),
> which saves the SSE/SSE2 context as well as the FP/MMX context.  This
> would allow us to set the bit to enable SSE/SSE2 support so Pentium3/4
> and Athlon optimized vector instructions could be used.

Would this allow MMX/SSE/SSE2 instructions in the kernel?  Someone was asking 
about this a little while back, although to be honest I forget why..

-- 
Vanders
http://syllable.sourceforge.net/
http://www.liqwyd.com