Subject: Re: [PATCH 1/5] split clocksource adjustment from clockosurce mult
From: John Stultz <johnstul@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
In-Reply-To: <Pine.LNX.4.64.0803150526060.1791@scrub.home>
References: <1205553852.6122.76.camel@localhost.localdomain>
	 <1205553938.6122.79.camel@localhost.localdomain>
	 <Pine.LNX.4.64.0803150526060.1791@scrub.home>
Content-Type: text/plain
Date: Fri, 14 Mar 2008 22:07:00 -0700
Message-Id: <1205557620.6173.5.camel@jstultz-laptop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1040
Lines: 32


On Sat, 2008-03-15 at 05:28 +0100, Roman Zippel wrote:
> Hi,
> 
> On Fri, 14 Mar 2008, john stultz wrote:
> 
> > @@ -179,7 +181,7 @@ static inline cycle_t clocksource_read(struct clocksource *cs)
> >  static inline s64 cyc2ns(struct clocksource *cs, cycle_t cycles)
> >  {
> >  	u64 ret = (u64)cycles;
> > -	ret = (ret * cs->mult) >> cs->shift;
> > +	ret = (ret * (cs->mult + cs->mult_adj)) >> cs->shift;
> >  	return ret;
> >  }
> 
> This add an extra memory access and extra instruction to a code path, we 
> should keep as short as possible.
> I'd rather add a mult_raw or mult_org and use that for your next patch.

Yea, I played with that at first, but the functoinal duplication (two
values, both storing close to the same info) was ugly. 

I guess I could go back to mult_orig.

-john


--
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/