On Tue, 2002-09-17 at 14:04, Jun Sun wrote: > > I am rewriting the FPU management code with the following > objectives in my mind: > > 1) to make it work for SMP. Right now, processes can migrate > to different CPUs leaving their FPU context on another CPU. > And the global variable last_task_used_math is shared by > multiple CPUs. :-) > I took a stab at this for a couple hours a while back, and didn't come up with anything I liked. But I may have some insights for you. > 2) save PFU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on next use of FPU. > > Need to use an additional flag to remember whether it is used > in the current run. Perhaps overridding used_math? In that > case, used_math == 2 indicates it used in the current run. > used_math is set back to 1 when process is switched off. > > Very simply to implement. > > 3) save FPU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on the next use of FPU and *only* if other > processes have tampered FPU context since the last use of FPU by > the current process. > > This requires each CPU to remember the last owner of FPU. > In order to support possible process migration cases in a SMP > system, each process also needs to remember the processor > on which it used FPU last. A process has a valid live FPU > context on a CPU if those two variables match to each other. > Therefore we can avoid unnecessary restoring FPU context. > > Fairly complex in implementation. > I'd argue for something between 2 & 3. Always save FPU state, and if you know the state has been preserved for the next run, skip the restore. I'm a bit leery of the whole "don't restore FPU state on context switch until you use the FPU again" idea as it's added complexity and I'm not at all sure you're going to see any measurable performance gain out of it. Certainly on an FPU-intensive process this is going to be a loss. > > 4) don't save or restore any FPU context during context switches. > Instead, we implement a full SMP-safe version of lazy fpu > switch. > > This introduces three states in terms of FPU context status: > a) live FPU context in current CPU > b) saved FPU context in memory > c) live FPU context in another CPU > Before we only have a) and b) states. c) is new in this approach. > > To deal with c), we need to provide an inter-processor call so that > we can ask another CPU to save FPU context in case we need to access > it on this CPU. > > Additionally we need similar variables required in 3) to keep track > who owns FPU at any time. > > Very complex to implement. Has the best performance, though. > Just say no. I doubt this will have the best performance on SMP, just because the process of getting the state off of the other CPU is going to be extremely costly. I'd rather see #1 just for simplicity's sake before #4... > Currently I am leaning towards 2) or 3). What is your opinion? > Something quick and dirty that I ended up doing recently was to bind fpu users to the CPU they we're using at the time of the first FPU fault. The last_task_used_math expansion is straightforward and it seemed to work pretty well. -Justin
Attachment:
signature.asc
Description: This is a digitally signed message part
