From owner-freebsd-current Tue Apr 3 9:17:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 12B3837B71B; Tue, 3 Apr 2001 09:17:34 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f33GGtK45818; Tue, 3 Apr 2001 09:16:55 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f33GFXB18156; Tue, 3 Apr 2001 09:15:33 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 03 Apr 2001 09:15:33 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: i586 FP optimizations hosed. Cc: "David O'Brien" , current@FreeBSD.org, Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Apr-01 Bruce Evans wrote: > 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. Hmmmmm. I think I'm liking the next to last. Even if there is additional overhead, it should still outperform generic_bcopy and friends on the CPU's in question, right? > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message