Date: Wed, 15 Feb 2006 13:26:01 +0100 (CET)
From: Roman Zippel <zippel@linux-m68k.org>
To: Ingo Molnar <mingo@elte.hu>
cc: Andrew Morton <akpm@osdl.org>, Thomas Gleixner <tglx@linutronix.de>,
       linux-kernel@vger.kernel.org, John Stultz <johnstul@us.ibm.com>
Subject: Re: [patch] hrtimer: round up relative start time on low-res arches
In-Reply-To: <20060215091959.GB1376@elte.hu>
Message-ID: <Pine.LNX.4.61.0602151259270.30994@scrub.home>
References: <Pine.LNX.4.61.0602130207560.23745@scrub.home>
 <1139827927.4932.17.camel@localhost.localdomain> <Pine.LNX.4.61.0602131208050.30994@scrub.home>
 <20060214074151.GA29426@elte.hu> <Pine.LNX.4.61.0602141113060.30994@scrub.home>
 <20060214122031.GA30983@elte.hu> <Pine.LNX.4.61.0602150033150.30994@scrub.home>
 <20060215091959.GB1376@elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1114
Lines: 24

Hi,

On Wed, 15 Feb 2006, Ingo Molnar wrote:

> yeah, agreed. That will be accurately fixed via GTOD's per-hwclock 
> resolution values. It will have another advantage as well: e.g. the 
> whole of m68k wont be penalized via CONFIG_TIME_LOW_RES for having a 
> handful of sub-arches (Apollo, Sun3x, Q40) that dont have a higher 
> resolution timer - every clock can define its own resolution. You could 
> help that effort by porting m68k to use GTOD ;-)

I'll do that as soon as the perfomance is equal or better than what we 
have right now and expensive 64bit math in the fast path, where it's 
provably a waste, is not exactly encouraging. I already provided all the 
math and code to keep it cheap and (relatively) simple, but I don't have 
the time to work constantly on it, so if you'd help to integrate it into 
John's work it would go a lot faster.

bye, Roman
-
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/