From owner-freebsd-current Tue Apr 3 5: 1:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AF84D37B71C; Tue, 3 Apr 2001 05:01:55 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA04646; Tue, 3 Apr 2001 22:01:52 +1000 Date: Tue, 3 Apr 2001 22:00:38 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , current@FreeBSD.org, "David O'Brien" Subject: Re: i586 FP optimizations hosed. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message