All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC] FPU context switch
Date: Wed, 18 Sep 2002 09:53:46 -0700	[thread overview]
Message-ID: <20020918095346.T17321@mvista.com> (raw)
In-Reply-To: <003c01c25eee$cfb41c30$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 10:38:38AM +0200

On Wed, Sep 18, 2002 at 10:38:38AM +0200, Kevin D. Kissell wrote:
> From: "Jun Sun" <jsun@mvista.com>
> > On Wed, Sep 18, 2002 at 01:44:57AM +0200, Kevin D. Kissell wrote:
> > > 
> > > I'd much prefer something that is simple and processor-local,
> > > even if it may be less optimal in some corner cases.  For example,
> > > Why not simply use CP0.Status.CU1 as a "dirty" bit?  If it's set 
> > > when a process switches out, the FPU state gets saved, and CU1 
> > > cleared.  If it's not set when a process hits an FP instruction, 
> > > CU1 gets set and the context gets loaded. This involves no 
> > > access whatever to shared control variables, indeed, it doesn't 
> > > even go to memory to make the decision. It will, of course, save 
> > > some FP contexts that don't need saving, but it is well behaved
> > > in the cases I care most about - it avoids saving/restoring FPRs
> > > of code that is doing no FP whatsoever, and it ensures that
> > > whenever a thread starts up, whatever CPU its on, its full
> > > context is available to that CPU, no (coherent) questions asked.
> > > 
> > 
> > This is basically 2) except for dirty bit difference.
> > 
> > My current implementaion uses bit:1 in task->used_math flag for 
> > "dirty" bit purpose.
> 
> Which is not a property of the CPU, but of the thread,
> meaning that it will be written by one CPU and read by
> another, i.e. there will be MP memory traffic and cache
> interventions/invalidations/misses around the operation.
>

In all places the task is "current" process.  Therefore no inter-processor
traffic.

Obiviously it is still less desriable than a bit in cpu regiters....

Jun

  reply	other threads:[~2002-09-18 17:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-17 18:04 [RFC] FPU context switch Jun Sun
2002-09-17 18:31 ` Greg Lindahl
2002-09-17 18:35   ` Jun Sun
2002-09-17 18:42 ` justinca
2002-09-17 18:48   ` Jun Sun
2002-09-17 19:03     ` Greg Lindahl
2002-09-17 19:38       ` Daniel Jacobowitz
2002-09-17 21:44 ` Dominic Sweetman
2002-09-17 21:58   ` Matthew Dharm
2002-09-17 21:58     ` Matthew Dharm
2002-09-17 22:30     ` Kevin D. Kissell
2002-09-17 22:30       ` Kevin D. Kissell
2002-09-17 22:58       ` Greg Lindahl
2002-09-17 23:03         ` Jun Sun
2002-09-17 23:44 ` Kevin D. Kissell
2002-09-17 23:44   ` Kevin D. Kissell
2002-09-17 23:45   ` Jun Sun
2002-09-18  8:38     ` Kevin D. Kissell
2002-09-18  8:38       ` Kevin D. Kissell
2002-09-18 16:53       ` Jun Sun [this message]
2002-09-18  8:29 ` Carsten Langgaard

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=20020918095346.T17321@mvista.com \
    --to=jsun@mvista.com \
    --cc=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    /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.