Message-ID: <37F397FE.3AD719FD@netapp.com>
From: Randy Thelen <rthelen@netapp.com>
Organization: Network Appliance Inc.
X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.0 i686)
MIME-Version: 1.0
Newsgroups: comp.os.minix
Subject: Re: On tty_inhibited
References: <37E7CE9D.F74021E9@unex.es> <37F0EB85.16EB59E4@netapp.com> <37F1E6A5.363309C0@unex.es>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Lines: 36
Date: Thu, 30 Sep 1999 10:03:58 -0700
NNTP-Posting-Host: 10.100.4.73
X-Complaints-To: kls@netapp.com
X-Trace: chrome.eng.netapp.com 938710919 10.100.4.73 (Thu, 30 Sep 1999 10:01:59 PDT)
NNTP-Posting-Date: Thu, 30 Sep 1999 10:01:59 PDT
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.ecn.ou.edu!newsfeed.berkeley.edu!su-news-hub1.bbnplanet.com!sanjose-news-feed1.bbnplanet.com!news.gtei.net!chrome.eng.netapp.com!not-for-mail

> Randy Thelen escribi:
> > Those are the only direct function calls I can see.  Drop the '&&
> > !inhibited' thing, if you think it will speed things up significantly.
> > :-)

Juan Carlos Daz Martn wrote:

> yes :-)

Um.  Actually, dropping small things like this won't speed the kernel
up.  Any.  You wouldn't be able to measure even if you used the
processor's performance counters.  I gaurantee it.  Places where the
kernel spends its time are in larger data structure failures.  For
example, when checking to see which processes to wake up, the entire
list of processes is checked (at least it was in 1.5 sources, I don't
know if that's been cleaned up with linked lists).  THAT can be seen
with a stop watch, performance counters are too fine grained to see that
sort of gross behavior.

So, performance is a tricky thing: don't try to fine tune the kernel by
removing small sequences of C code (what will become two or three
processor instructions).  Attempt to find the gross performance
violations, such as O(N) operations (for N = number of processes in the
system) instead of O(N^2) or O(2^N) [I don't know of any of those in the
kernel ... do you?].  Another area of performance tuning is to find O(N)
operations and reduce N.  So, instead of the number of processes in the
system, reduce N to the number of processes blocked on a particular
signal.  Any place where the kernel has a for(i = 0 ; i < NR_PROC; i++)
is a damn good candidate for this type of performance reduction.  Often
this requires an additional data structure element (or, heaven forbid,
an entirely new data structure) and that may mean cooperation between
fs/*.c and mm/*.c code.  So, you'll learn -A LOT!!-.

That's how I'd spend my free time had I any.  :-)

-- Randy
