Message-ID: <3DA5A9D6.D72A8E00@mvista.com>
Date: Thu, 10 Oct 2002 09:24:54 -0700
From: george anzinger <george@mvista.com>
Organization: Monta Vista Software
MIME-Version: 1.0
To: Oliver Xymoron <oxymoron@waste.org>
CC: Linus Torvalds <torvalds@transmeta.com>,
       "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1
References: <Pine.LNX.4.44.0210091613590.9234-100000@home.transmeta.com> <3DA4BECB.9C7D6119@mvista.com> <20021010155424.GN21400@waste.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4479
Lines: 98

Oliver Xymoron wrote:
> 
> On Wed, Oct 09, 2002 at 04:42:03PM -0700, george anzinger wrote:
> > Linus Torvalds wrote:
> > >
> > > On Wed, 9 Oct 2002, george anzinger wrote:
> > > >
> > > > This patch, in conjunction with the "core" high-res-timers
> > > > patch implements high resolution timers on the i386
> > > > platforms.
> > >
> > > I really don't get the notion of partial ticks, and quite frankly, this
> > > isn't going into my tree until some major distribution kicks me in the
> > > head and explains to me why the hell we have partial ticks instead of just
> > > making the ticks shorter.
> > >
> > Well, the notion is to provide timers that have resolution
> > down into the micro seconds.  Since this take a bit more
> > overhead, we just set up an interrupt on an as needed
> > basis.  This is why we define both a high res and a low res
> > clock.  Timers on the low res clock will always use the 1/HZ
> > tick to drive them and thus do not introduce any additional
> > overhead.  If this is all that is needed the configure
> > option can be left off and only these timers will be
> > available.
> >
> > On the other hand, if a user requires better resolution,
> > s/he just turns on the high-res option and incures the
> > overhead only when it is used and then only at timer expire
> > time.  Note that the only way to access a high-res timer is
> > via the POSIX clocks and timers API.  They are not available
> > to select or any other system call.
> >
> > Making ticks shorter causes extra overhead ALL the time,
> > even when it is not needed.  Higher resolution is not free
> > in any case, but it is much closer to free with this patch
> > than by increasing HZ (which, of course, can still be
> > done).  Overhead wise and resolution wise, for timers, we
> > would be better off with a 1/HZ tick and the "on demand"
> > high-res interrupts this patch introduces.
> 
> I think what Linus is getting at is: why not make the units of jiffies
> microseconds and give it larger increments on clock ticks? Now you
> don't need any special logic to go to better than HZ resolution.
> Unfortunately, this means identifying all the things that use HZ as a
> measure of how often we check for rescheduling.

Well then you are still dealing with two measures, the HZ
and the tick rate.  One might also argue that the subjiffie
should be some "normal" thing like nanosecond or micro
second.  I went round and round with this in the beginning. 
What it comes down to it the conversion back and forth is
much easier and faster (less overhead) when using the
natural units of the underlying clock.  This way the
interrupt code, for example, does not have to even do a
conversion.
> 
> There's also an issue of dynamic range - if we some day soon decide we
> want internal timestamps with nanosecond resolution (because units of
> .1us are annoying, not because we'll actually have ns accuracy),
> then we're seeing timer wraps every couple seconds on 32bit machines
> and we're pretty much forced to break into seconds and nanoseconds.
> This is arguably saner than jiffies and subjiffies, but it forces
> people who are using long timeouts today to use a new interface.
> 
> I don't think he can seriously mean cranking HZ up to match whatever
> timing requirements we might have - that obviously doesn't scale.

This is at least the third "take" on what he means, each of
which sends me in a very different direction.  Sure would
like to know what he really means.

I KNOW there is demand for the high-res timers, else I would
not have spent the last year + being funded to do it.  It
also would not be in the OSDL Carrier Grade system if there
was no demand. 

What I would really like to do is address the real issue.
> 
> --
>  "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/