hires timer patchset [was Re: 2.6.19 -mm merge plans]

[Bill Rugolsky Jr.]

On Fri, Sep 22, 2006 at 09:01:06PM +0200, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@xxxxxxx> wrote:
> 
> > > would be nice to merge the -hrt queue that goes right ontop this 
> > > queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That 
> > > gives us high-res timers and dynticks which are both very important 
> > > features to certain classes of users/devices.
> > 
> > dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on 
> > thinkpad x60... and they were around for way too long. (When baseline 
> > is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to 
> > finally merge them.
> 
> note that this is a new implementation of dynticks though, not Con's 
> older stuff which you probably used, right? But it's fairly low-impact 
> (just a few lines ontop of hrtimers, here and there), ontop of the 
> long-existing -hrt queue.

Just a data point, FWIW; I've made no systematic effort to find regressions.

We've been running Thomas's (pre-dynticks) 2.6.16-hrt patchset (and
HZ=1000) without issue as part of my standard kernel build on x86 and
x86_64 UP/SMP production hosts -- workstations, PostgreSQL (and other)
servers, and routers --- since I experienced latency/ntp problems with
an unpatched kernel using sata_nv on Tyan 2895 Nvidia CK804-chipset mobo
back in March 2006.  I've also been running the (originally x86-only)
2.6.17-dynticks patch on a Tyan Athlon SMP workstation mobo, and occasionally
on my laptop, so far without issue.

I originally chose Thomas's -hrt variant of John Stultz's timekeeping
patchset because it had known-working x86_64 support ...

We're not doing anything exotic (such as audio, packet capture,
or serving thousands of connections) that might stress the timer or
clock system much, but the x86 routers have GigE traffic and the
x86_64 PostgreSQL servers are often heavily loaded.

Regards,

	Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/