All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jun Sun <jsun@mvista.com>
Cc: Greg Lindahl <lindahl@conservativecomputer.com>, linux-mips@oss.sgi.com
Subject: Re: FPU emulator unsafe for SMP?
Date: Wed, 20 Feb 2002 14:18:41 +0100	[thread overview]
Message-ID: <20020220141841.E15588@dea.linux-mips.net> (raw)
In-Reply-To: <20020219202434.F25739@mvista.com>; from jsun@mvista.com on Tue, Feb 19, 2002 at 08:24:34PM -0800

On Tue, Feb 19, 2002 at 08:24:34PM -0800, Jun Sun wrote:

> > What you propose, locking the fpu owner to the current cpu, will not
> > result in a fair solution. Imagine a 2 cpu machine with 2 processes
> > using integer math and 1 using floating point... how much cpu time
> > will each process get? 
> 
> In this case, proc that uses fpu gets about 50% of one cpu, i.e., 25% of
> total load, while the other two integer math proces split the rest 75%,
> which gives 37.5% each.  Not too bad in my opinion.

Certainly not good either.  Still not having checked the x86 solution
I currently favor the approach of only always storing the fp context
but lazily restoring it.

  Ralf

  parent reply	other threads:[~2002-02-20 15:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-15  1:56 FPU emulator unsafe for SMP? Jun Sun
2002-02-15  2:11 ` Ralf Baechle
2002-02-15  7:20   ` Jun Sun
2002-02-15  8:30     ` Jun Sun
2002-02-15  9:59       ` Kevin D. Kissell
2002-02-15  9:59         ` Kevin D. Kissell
2002-02-19 22:05         ` Jun Sun
2002-02-19 22:19           ` Ralf Baechle
2002-02-20  0:08           ` Kevin D. Kissell
2002-02-20  0:08             ` Kevin D. Kissell
2002-02-20  1:12             ` Jun Sun
2002-02-20  3:28               ` Greg Lindahl
2002-02-20  4:24                 ` Jun Sun
2002-02-20  4:32                   ` Daniel Jacobowitz
2002-02-20  9:48                     ` Jun Sun
2002-02-20 10:14                     ` Kevin D. Kissell
2002-02-20 10:14                       ` Kevin D. Kissell
2002-02-20 13:50                       ` Ralf Baechle
2002-02-20 20:53                         ` Greg Lindahl
2002-02-20 13:24                     ` Ralf Baechle
2002-02-20  4:48                   ` Greg Lindahl
2002-02-20  9:27                   ` Florian Lohoff
2002-02-20 13:18                   ` Ralf Baechle [this message]
2002-02-20  9:56                 ` Geert Uytterhoeven
2002-02-20 11:14                   ` Kevin D. Kissell
2002-02-20 13:10                 ` Ralf Baechle
2002-02-20  8:27               ` Dominic Sweetman
2002-02-20  9:30                 ` Florian Lohoff
2002-02-20 13:56                   ` Ralf Baechle
2002-02-20 13:09               ` Ralf Baechle
2002-02-20 14:42                 ` Kevin D. Kissell
2002-02-20 14:42                   ` Kevin D. Kissell
2002-02-20 14:46                 ` Maciej W. Rozycki
2002-02-20 15:05                   ` Ralf Baechle
2002-02-20 15:45                     ` Maciej W. Rozycki
2002-02-20 13:03             ` Ralf Baechle
2002-02-15  8:14 ` Kevin D. Kissell
2002-02-15  8:14   ` Kevin D. Kissell
2002-02-15 10:57   ` Ralf Baechle
2002-02-19 22:02     ` Jun Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020220141841.E15588@dea.linux-mips.net \
    --to=ralf@oss.sgi.com \
    --cc=jsun@mvista.com \
    --cc=lindahl@conservativecomputer.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.