public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Andre Hedrick <andre@linux-ide.org>
Cc: 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: Thu, 12 Apr 2001 19:58:42 -0700	[thread overview]
Message-ID: <3AD66B62.23620639@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10104121616070.4564-100000@master.linux-ide.org>

Andre Hedrick wrote:
> 
> On Fri, 13 Apr 2001, Alan Cox wrote:
> 
> > > Okay but what will be used for a base for hardware that has critical
> > > timing issues due to the rules of the hardware?
> >
> > > #define WAIT_MIN_SLEEP  (2*HZ/100)      /* 20msec - minimum sleep time */
> > >
> > > Give me something for HZ or a rule for getting a known base so I can have
> > > your storage work and not corrupt.
> >
> >
> > The same values would be valid with add_timer and friends regardless. Its just
> > that people who do
> >
> >       while(time_before(jiffies, started+DELAY))
> >       {
> >               if(poll_foo())
> >                       break;
> >       }
> >
> > would need to either use add_timer or we could implement get_jiffies()

Actually we could do the same thing they did for errno, i.e.

#define jiffies get_jiffies()
extern unsigned get_jiffies(void);

> 
> Okay regardless of the call what is it going to be or do we just random
> and go oh-crap data!?!?
> 
> Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale
> that FS corruption and system death is not more rampant, except for the
> fact that hardware is quick by a factor of 10+ so that 1000 does not quite
> do as much harm but the associated mean of HZ changes and that is a
> problem with slower hardware.

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.

George

  reply	other threads:[~2001-04-13  3:00 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 [this message]
2001-04-13  4:04         ` Andre Hedrick
2001-04-13  7:21           ` Eric W. Biederman
2001-04-13  8:28             ` george anzinger
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=3AD66B62.23620639@mvista.com \
    --to=george@mvista.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --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