All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Sieler <sieler@allegro.com>
To: alan@linuxcare.com.au (Alan Modra)
Cc: jsm@udlkern.fc.hp.com (John Marvin),
	parisc-linux@puffin.external.hp.com,
	parisc-linux@thepuffingroup.com
Subject: Re: Single-stepping
Date: Mon, 20 Nov 2000 10:47:38 -0800 (PST)	[thread overview]
Message-ID: <200011201847.KAA12667@opus.allegro.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0011201912260.15391-100000@front.linuxcare.com.au> from "Alan Modra" at Nov 20, 2000 08:05:58 PM

Re:

> Because you would then need to save and restore cr0 on task switches (or
> only allow one task to be single-stepped at a time).  That's four
> instructions and two extra memory accesses per task switch.  Which might
> not seem very much, but at some point somebody will no doubt start caring
> about pa-linux performance. 

And it still won't seem like much, then!

Non-memory-access instructions are cheap.  An extra memory reference (from
something probably already in cache) and two extra instructions
would probably cost less than an hour per CPU over the next 10 *years*,
assuming 10 years of 1000 task switches per second on a slow 100 MHz CPU.

Of course, at the cost of an extra non-memory-referencing instruction or so,
you could say "at switch-to-task time: if PSW R-bit set, then load the saved
CR0 from memory and move it to CR0", saving one memory reference 99.99999%
of the time, resuling in an average of only one memory reference
per task switch normally.

I haven't look at interrupt handling / system calls closely, but I
hope there aren't other false savings.  (E.g., failure to save/restore
the PID check flag ... sure, user processes *now* probably never have
pid checking disabled, but that's a very useful feature to have
available (with proper security controls, of course).)
(Yes, I'm one of the very few who use that feature on MPE/iX ... carefully,
of course :)

-- 
Stan Sieler                                           sieler@allegro.com
www.allegro.com/sieler/wanted/index.html                  www.sieler.com        

  reply	other threads:[~2000-11-20 18:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-20  5:43 Single-stepping John Marvin
2000-11-20  6:53 ` Single-stepping Alan Modra
2000-11-20  7:24   ` Single-stepping Stan Sieler
2000-11-20  9:05     ` Single-stepping Alan Modra
2000-11-20 18:47       ` Stan Sieler [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-16 12:44 Single-stepping John Marvin
2000-11-16 13:20 ` Single-stepping Richard Hirst
2000-11-16 19:00 ` Single-stepping Frank Rowand
2000-11-16 20:28   ` Single-stepping Richard Hirst
2000-11-16  9:01 Single-stepping John Marvin
2000-11-16 12:00 ` Single-stepping Richard Hirst
2000-11-20  3:03 ` Single-stepping Alan Modra

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=200011201847.KAA12667@opus.allegro.com \
    --to=sieler@allegro.com \
    --cc=alan@linuxcare.com.au \
    --cc=jsm@udlkern.fc.hp.com \
    --cc=parisc-linux@puffin.external.hp.com \
    --cc=parisc-linux@thepuffingroup.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.