In article <[EMAIL PROTECTED]> you wrote:
> On Wed, 20 Sep 2000, Timur Tabi wrote:
> Well the code does a fnsave. Somebody never looked at the damn book! it
> takes 143 clocks for this, plus at least 3 for fwait. Then it sets a
> flag to let return code 'know' if the context has to be restored.
On Thu, 21 Sep 2000, Alan Cox wrote:
> > > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> > >
> > > Unless you sleep
> >
> > Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> > do the right thing at least on x86. Your kernel FPU state will overwr
> Well the code does a fnsave. Somebody never looked at the damn book! it
Oh I did. And then I timed the performance for the copying cases
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://w
On Thu, Sep 21, 2000 at 11:28:26PM +0100, Alan Cox wrote:
> > > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> > >
> > > Unless you sleep
> >
> > Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> > do the right thing at least on x86. Your kernel F
> > > It is sufficient when you do tsk->flags |= PF_USEDFPU first.
> >
> > Unless you sleep
>
> Unless I'm missing something the lazy FPU state save in the 2.4 switch_to will
> do the right thing at least on x86. Your kernel FPU state will overwrite the
> user FPU state in current, but that's o
On Thu, Sep 21, 2000 at 11:08:36PM +0100, Alan Cox wrote:
> > On Thu, Sep 21, 2000 at 11:36:17AM +, John Alvord wrote:
> > > A 2.5-time problem is that portions of the kernel are planned to
> > > become interruptible... so saving and restoring around a certain usage
> > > would be insufficient
> On Thu, Sep 21, 2000 at 11:36:17AM +, John Alvord wrote:
> > A 2.5-time problem is that portions of the kernel are planned to
> > become interruptible... so saving and restoring around a certain usage
> > would be insufficient.
>
> It is sufficient when you do tsk->flags |= PF_USEDFPU first
> On Wed, 20 Sep 2000, Lyle Coder wrote:
> >You cannot use MMX registers in the kernel either, since the kernel doesen't
> >save and restore FX state (fxsave, fxrstor) either (just like
> >(fsave/frstor).
>
> You might want to tell the software RAID maintainers that... RAID5 CRC
> calculations
On Thu, Sep 21, 2000 at 11:36:17AM +, John Alvord wrote:
> A 2.5-time problem is that portions of the kernel are planned to
> become interruptible... so saving and restoring around a certain usage
> would be insufficient.
It is sufficient when you do tsk->flags |= PF_USEDFPU first.
Anyways,
On Wed, 20 Sep 2000 22:37:29 -0700, "Lyle Coder" <[EMAIL PROTECTED]>
wrote:
>Hi
>The real issue is that if you use MMX or FP state, the kernel _must_ save
>and restore the original state other wise user programs will see corruption.
>We all know this too well since redhat's 6.1 (I think) kernel h
Lyle
- Original Message -
From: "Ricky Beam" <[EMAIL PROTECTED]>
To: "Lyle Coder" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 20, 2000 9:13 PM
Subject: Re: Question: Using floating point in the kernel
> On Wed, 20 Sep 2000, Lyl
On Wed, 20 Sep 2000, Lyle Coder wrote:
>You cannot use MMX registers in the kernel either, since the kernel doesen't
>save and restore FX state (fxsave, fxrstor) either (just like
>(fsave/frstor).
You might want to tell the software RAID maintainers that... RAID5 CRC
calculations can be done wi
In message <[EMAIL PROTECTED]> you
write:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel?
Please read the documentation, found in
linux/Documentation/DocBook/kernel-hacking.tmpl
See `No floating point or MMX'
Rusty.
--
Hacking time.
-
T
On Wed, 20 Sep 2000, Timur Tabi wrote:
> ** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000
> 01:50:05 GMT
>
>
> > You cannot use MMX registers in the kernel either, since the kernel doesen't
> > save and restore FX state (fxsave, fxrstor) either (just like
> > (fsa
Timur Tabi wrote:
>
> ** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000
> 01:50:05 GMT
>
> > You cannot use MMX registers in the kernel either, since the kernel doesen't
> > save and restore FX state (fxsave, fxrstor) either (just like
> > (fsave/frstor).
>
> But wha
** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000
01:50:05 GMT
> You cannot use MMX registers in the kernel either, since the kernel doesen't
> save and restore FX state (fxsave, fxrstor) either (just like
> (fsave/frstor).
But what about these source files:
inclu
On Tue, 19 Sep 2000, Richard B. Johnson wrote:
> long int radians = (long) (2.0 * 3.141592654 * (float) HZ);
Just out of curiosity: what's that cast to float about? Have it spring
into the eye of a casual reader? That pi constant already is a double
and C implicitly casts to the type with
Hello,
You cannot use MMX registers in the kernel either, since the kernel doesen't
save and restore FX state (fxsave, fxrstor) either (just like
(fsave/frstor).
Best Wishes,
Lyle
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on
Tue,
19 Sep 2000 11:58:34 -0400 (EDT)
>Tel
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Tue,
19 Sep 2000 11:58:34 -0400 (EDT)
> Tell the driver maintainer that you found a BUG. There is no floating-
> point allowed in the kernel because the state of the FP Unit is
> undefined in the kernel. If you 'define' it, i.e
[EMAIL PROTECTED] (Michael Vines) writes:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should t
On Tue, 19 Sep 2000, Michael Vines wrote:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should t
I was just wondering if you can use floating point while servicing a
syscall in the kernel? Doing a
find -name \*.c -exec grep float {} \; -print
turned up a couple drivers that seem to be using fp. Are there any
known issues that I should to be aware off?
Thanks,
Mike
-
To
22 matches
Mail list logo
