On Mon, 2 Apr 2001, John Baldwin wrote:

> On 31-Mar-01 Bruce Evans wrote:
> > [about i586-optimized copying and bzeroing]
> > - we start using the FPU on a CPU with a free FPU (we used to free the
> >   FPU in some cases; now we only use optimizations in bcopy/bzero if
> >   the FPU was free to begin with).
> > - we do a preemptive context switch and come back using a different FPU.
> > 
> > The different CPU might even be unfree, and that case is now detected.
> > In other cases, we just corrupt data by using different FPU registers :-(.
> Ugh.  Hrm, then we need to either disable interrupts inside of i586_* or set a

This would break fast interrupts :-).

> hard affinity flag in the process such that all other CPU's will ignore it and
> only p_lastcpu will run it next.

There are many other possibilities:
- don't use these routines.
- don't use these routines for the SMP case.
- disable preemptive context switching for the CPU that is using the FPU.
  The hard affinity flag could be used for this as a special case.
- acquire sched_lock so that all sorts of context switching are disabled
  for all CPUs.
- don't attempt to save the FPU state reentrantly, since this doesn't work
  with preemptive context switchiing unless interrupt handlers also save the
  state reentrantly, which they shouldn't do because it is too wasteful.
  Instead, save the state in the pcb as is already done in copy{in,out}
  so that cpu_switch() handles it.  This may be too wasteful too.
- as in previous possibility, but avoid switching the entire state.  For
  the FPU, the entire state must be switched, but for SSE individual
  registers can be saved and restored.  Saving and restoring individual
  registers reentrantly would be easy but no longer works for the SMP case.
  Switching a subset of the state would not be so easy.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to