public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andre Hedrick <andre@linux-ide.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org,
	high-res-timers-discourse@lists.sourceforge.net
Subject: Re: Linux-Kernel Archive: No 100 HZ timer !
Date: Fri, 13 Apr 2001 01:28:04 -0700	[thread overview]
Message-ID: <3AD6B894.39848F3F@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10104122102170.4564-100000@master.linux-ide.org> <m1snjdtgcc.fsf@frodo.biederman.org>

"Eric W. Biederman" wrote:
> 
> Andre Hedrick <andre@linux-ide.org> writes:
> 
> > On Thu, 12 Apr 2001, george anzinger wrote:
> >
> > > Actually we could do the same thing they did for errno, i.e.
> > >
> > > #define jiffies get_jiffies()
> > > extern unsigned get_jiffies(void);
> >
> > > No, not really.  HZ still defines the units of jiffies and most all the
> > > timing is still related to it.  Its just that interrupts are only "set
> > > up" when a "real" time event is due.
> >
> > Great HZ always defines units of jiffies, but that is worthless if there
> > is not a ruleset that tells me a value to divide by to return it to a
> > specific quantity of time.

The definition of HZ is the number of units in a second.  Thus if HZ is
100 we are talking about a 10 ms jiffie.
> 
> Actually in rearranging it.  jiffies should probably be redefined as
> the smallest sleep we are prepared to take.  And then HZ because the
> number of those smallest sleeps per second.  So we might see HZ values
> up in the millions but otherwise things should be pretty much as
> normal.

Actually I think it is more useful to define it as something like 100
for the following reasons.  

I think it makes the most sense to keep jiffie as a simple unsigned
int.  If we leave drivers, and other code as is they can deal with
single word (32 bit) values and get reasonable results.  If we make HZ
too high (say 10,000 to get micro second resolution) we will start
limiting the max time we can handle, in this case to about 71.5 hours. 
(Actually 1/2 this value would start giving us trouble.)  HZ only
affects the kernel internals (the user API is either seconds/micro
seconds or seconds/nano seconds).  For those cases where we want a higer
resolution we just add a sub jiffie component.  Another way of looking
at this is to set up HZ as the "normal" resolution.  This would be the
resolution (as it is today) of the usual API calls.  Only calls to the
POSIX 1b timers would be allowed to have higher resolution.  I propose
that we use the POSIX standard to define "CLOCKS" with various
resolution, with the understanding that the higher resolutions will have
higher overhead.  An yet another consideration, to get high resolution
with a reasonable maximum timer interval we will need to use two words
in the timer.  I think it makes sense to use the jiffie (i.e. 1/HZ) as
the high order part of the timer's time.  

Note that all of these considerations on jiffie size hold with or with
out a tick less system.

George

  reply	other threads:[~2001-04-13  8:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3AD622AB.5F0A061B@linux-ide.org>
2001-04-12 21:52 ` Linux-Kernel Archive: No 100 HZ timer ! Andre Hedrick
2001-04-12 23:12   ` Alan Cox
2001-04-12 23:21     ` Andre Hedrick
2001-04-13  2:58       ` george anzinger
2001-04-13  4:04         ` Andre Hedrick
2001-04-13  7:21           ` Eric W. Biederman
2001-04-13  8:28             ` george anzinger [this message]
2001-04-13 12:20               ` Mark Salisbury
2001-04-13 12:55                 ` Michael Raymond
2001-04-13 15:50                 ` george anzinger
2001-04-13  9:05           ` David Schleef
2001-04-13 12:47           ` Alan Cox
2001-04-14 13:57   ` Rogier Wolff
2001-04-15  2:10   ` Roger Larsson
2001-04-15  7:22     ` george anzinger
2001-04-16 15:32   ` Pavel Machek

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=3AD6B894.39848F3F@mvista.com \
    --to=george@mvista.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --cc=ebiederm@xmission.com \
    --cc=high-res-timers-discourse@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.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