Date: Tue, 03 Apr 2001 09:15:33 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: "David O'Brien" <obrien@FreeBSD.org>, current@FreeBSD.org, Mark Murray <mark@grondar.za> Subject: Re: i586 FP optimizations hosed. Message-ID: <XFMail.010403091533.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0104032200080.32249-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010403091533.jhb>