Subject: Re: Floating point in the kernel
To: Brian C. Grayson <firstname.lastname@example.org>
From: David Brownlee <email@example.com>
Date: 09/18/1998 15:42:04
On Fri, 18 Sep 1998, Brian C. Grayson wrote:
> On Fri, Sep 18, 1998 at 08:52:34AM -0700, Chris G. Demetriou wrote:
> > firstname.lastname@example.org (Andreas Gustafsson) writes:
> > > So, I am wondering, is this lack of support for floating point in the
> > > kernel on the i386 port
> > >
> > > a) considered a bug or a feature?
> > Feature. It's a performance issue:
> > If you can use FP in the kernel, then unless you're very careful about
> > saves and restores around the places where you want to do FP work, you
> > need to save FP state in every interrupt and trap entry and exit
> > routine.
> I don't know what I'm talking about :), but since the use of FP
> is going to be rare, would something based on the following
> work (after suitable extension to cover all the potential
> problems I'm missing, like avoiding corrupting the user's FP
> a) upon entry into any device routines that use FP, you first
> increment global_using_fpregs.
> b) upon exit from any device routines that use FP, you
> decrement global_using_fpregs (and panic if it is already
> c) in the main interrupt handler, if global_using_fpregs > 0,
> save the FP registers, otherwise you don't have to.
I could be missing something here, but since nothing currently in
the kernel uses FPU, and all we have to preserve is user data
in FPU registers then if you are not using them in an interrupt
context, you can just save and restore around each use of the
registers? In a threaded kernel you could use a mutex lock to
ensure it all works.
Then you could conditionally compile in the code that uses the FPU
without needing to modify any other part of the kernel.
Obviously you need to ensure there is an FPU present, plus pay the
code for the saves/restores appropriately...
Abandoning a syncing disk... or syncing an abandoned disk?