linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tom Vier <thomassr@erols.com>
To: Rob Barris <rbarris@quicksilver.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: question about altivec registers
Date: Tue, 26 Oct 1999 18:03:54 -0400	[thread overview]
Message-ID: <19991026180354.A6577@zero> (raw)
In-Reply-To: <v03010d0cb43a9d52cd3e@[192.168.1.16]>


On Mon, Oct 25, 1999 at 04:53:52PM -0700, Rob Barris wrote:

>    I worked this out once, the extra 512 bytes of register context,
> multiplied by (say) a thousand context switches per second only add up to
> about a MB of memory traffic per second - a fraction of a percent of the
> available memory bandwidth in a G4 machine.  Most of that will sit in cac=
he
> anyway depending on the working set size of the processes involved.

couldn't you just do lazy context saves? ie, disable the vector ops by 
default; when a proc tries to use a vector op catch the exception, mark the
proc as vector using and enable vectors. when a context switch occurs,
mark the proc as vector enable, disable vectors, continue (and re-enable
when you switch the proc's context back in). it's a little more complicated
when more than one proc wants vectors. in that case, before you re-enable
vectors, check to see if the vector regs need their context switched.

or maybe that complexity isn't worth bandwidth/latency it saves.
does linux/ppc do lazy FPU context saves this way?

if you don't do lazy vector saves, i would think it would raise context
switch times a sizable amount. there's four times as much data in those
128bit regs as there are in the 32bit GPRs.

-- 
Tom Vier - 0x27371A1C
thomassr@erols.com
http://users.erols.com/thomassr/zero/

DSA Key fingerprint:
42D4 82D6 6DF5 77EC 1251  30D2 D9E7 E858 2737 1A2C

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~1999-10-26 22:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-25 20:51 question about altivec registers Jim Terman
1999-10-25 22:27 ` Claude Robitaille
1999-10-25 22:31   ` Jim Terman
1999-10-25 22:44     ` erik cameron
1999-10-25 23:28     ` Claude Robitaille
     [not found]     ` <Pine.LNX.4.10.9910251916060.5902-100000@modemcable220.93-200-24.mtl.mc.vi deotron.net>
1999-10-25 23:53       ` Rob Barris
1999-10-26 18:22         ` Geert Uytterhoeven
1999-10-26 22:13           ` Rob Barris
1999-10-26 22:38           ` Tom Vier
1999-10-26 22:03         ` Tom Vier [this message]
1999-10-26  4:42 ` Kumar Gala
1999-10-26 21:52   ` Jim Terman
1999-10-26 22:43     ` Kumar Gala
1999-10-27  8:58       ` Adrian Cox
1999-10-27 13:21         ` Gabriel Paubert
1999-10-27 16:05           ` Geert Uytterhoeven
1999-10-27 18:23           ` Kumar Gala
1999-10-27 22:39           ` Tony Mantler
1999-10-28 11:01             ` Gabriel Paubert
1999-10-28 21:20               ` Tony Mantler
1999-10-29 11:58                 ` Benjamin Herrenschmidt
1999-10-29 12:49                 ` Gabriel Paubert
1999-10-30  4:14                   ` Tony Mantler

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=19991026180354.A6577@zero \
    --to=thomassr@erols.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=rbarris@quicksilver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).