9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Performance
Date: Wed,  9 May 2001 08:57:57 -0400	[thread overview]
Message-ID: <20010509125804.9473E199E7@mail.cse.psu.edu> (raw)

On Wed May  9 04:44:05 EDT 2001, pschay@pobox.com wrote:
> Hi,
> 
> There are many things besides kernel compilation that
> are also really fast compared to other systems: booting,
> compiling the window system, running the window system,
> ....
> 
> Anyway, as fast as kernel compilation is, I do have some
> questions about the performance.  I tried a few ways of
> profiling the kernel during kernel compilation.  At first
> I found that a lot of the kernel time was spent in halt()
> so I changed HLT to NOP in l.s.  Now almost a third of the
> time is apparently spent in runproc().
> 
> Is this a fixable problem?  Or is it actually the desired
> behavior?  (All I can imagine is that maybe the scheduler
> sacrifices the good of the few for the good of the many and
> me + my measly kernel compilation processes are not the
> common case?  Or perhaps scheduling typically consumes this
> kind of overhead?)  I know zilch about schedulers so
> I'd greatly appreciate any insight, or pointers to
> literature.  I think I recall reading a brief posting a year
> or two ago by one of the experts who said something to the
> effect that the scheduler has lots of room for improvement.
> Why? How? Could anybody elaborate?
> 
> Thanks.
> -Pete

The system looks for processes to run by scanning the run queues
in runproc(). If it doesn't find anything it just keeps looking until
something is put in the queue. Nothing can be put in the queue
except by an external event happening, i.e. some interrupt causes
a process to change state. The HLT instruction waits until an
interrupt occurs then continues. As you observed, you can replace
HLT with a NOP (or take the call to the routine out entirely) to
no ill effect, and this is what the system used to do. However,
HLT gives the processor opportunities to conserve power and thereby
run cooler and lengthen battery life, etc.

Of course, on a multiprocessor, something can be put on the run
queue by another processor without an external event occurring on
this processor, so the HLT instruction isn't used in that case.

--jim


             reply	other threads:[~2001-05-09 12:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-09 12:57 jmk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-05-11 13:52 jmk
2001-05-10 17:21 jmk
2001-05-11  8:33 ` Douglas A. Gwyn
2001-05-09 14:47 Richard Miller
2001-05-10 15:14 ` Douglas A. Gwyn
2001-05-09 13:03 presotto
2001-05-09  8:58 forsyth
2001-05-09  6:03 nemo
2001-05-08 21:33 Russ Cox
2001-05-09  2:09 ` Ronald G Minnich
2001-05-10 15:15 ` Douglas A. Gwyn
2001-05-08 21:25 jmk
2001-05-08 18:20 jmk
2001-05-09  8:29 ` Peter Schay
2001-05-08 17:54 nemo
2001-05-08 18:46 ` Scott Schwartz
2001-05-08 17:42 Fariborz 'Skip' Tavakkolian
2001-05-08 18:07 ` aam396
2001-05-08 22:38 ` Boyd Roberts
2001-05-08 17:40 presotto
2001-05-08 18:45 ` Scott Schwartz
2001-05-09  5:35 ` Franklin Robert Araujo Fran€a
2001-05-10  8:43   ` Juhani Forsman

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=20010509125804.9473E199E7@mail.cse.psu.edu \
    --to=jmk@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /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).