Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Jun Sun" <jsun@mvista.com>
Cc: <linux-mips@linux-mips.org>, <jsun@mvista.com>
Subject: Re: [RFC] FPU context switch
Date: Wed, 18 Sep 2002 10:38:38 +0200	[thread overview]
Message-ID: <003c01c25eee$cfb41c30$10eca8c0@grendel> (raw)
In-Reply-To: 20020917164520.P17321@mvista.com

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.

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC] FPU context switch
Date: Wed, 18 Sep 2002 10:38:38 +0200	[thread overview]
Message-ID: <003c01c25eee$cfb41c30$10eca8c0@grendel> (raw)
Message-ID: <20020918083838.Jr65DZx4wCvpUlt3YGjMiqmOufVPNyDCg_nvY09HiRo@z> (raw)
In-Reply-To: 20020917164520.P17321@mvista.com

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.

            Kevin K.

  reply	other threads:[~2002-09-18  8:36 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 [this message]
2002-09-18  8:38       ` Kevin D. Kissell
2002-09-18 16:53       ` Jun Sun
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='003c01c25eee$cfb41c30$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=jsun@mvista.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox