[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160346908.5686.143.camel@localhost.localdomain>
Date: Mon, 09 Oct 2006 00:35:08 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Daniel Walker <dwalker@...sta.com>
Cc: akpm@...l.org, johnstul@...ibm.com, mingo@...e.hu,
zippel@...ux-m68k.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + clocksource-add-generic-sched_clock.patch added to -mm tree
On Sun, 2006-10-08 at 15:08 -0700, Daniel Walker wrote:
> > And why the heck does this require to move _clocksource_ related code
> > including sysfs hackery into timer.c ? Your improvement works with
> > extern code as well.
>
> There are no clocksource internals added by me. There is a exposed
> clocksource API which is all that is used.
You move tons of code into timer.c, which does not belong there.
clocksource is a different thing than timekeeping. timekeeping makes use
of clocksources, and your extra layer of timekeeping_clocksource API
does not change that at all. What you call abstraction is just an
artificial extra layer, as it is intrinsically tied to the clocksource
core.
> The design of the original clocksource interface was specific for
> timekeeping. What I did was modified it to be used by more than just
> timekeeping.
>
> If I add tons of externs there and cram all that into clocksource.c ,
> that would just be a mess. Then we're tending back to the original
> clocksource design when it's designed just for time keeping.
Tons of externs for the optimization of the clock source switch? Sorry,
I'm not following.
The clock source switch happens once or twice during bootup and the
replacement of a call with an atomic check does not in any way
legitimate the move of code into timer.c. The number of cylces saved is
not impressing. Moving the clock source switch out of that path at all
would be progress and save real cylces.
.
The maintainability of code has to weighed carefully against some
obscure cylce savings.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists