Re: + clocksource-add-generic-sched_clock.patch added to -mm tree

[Daniel Walker <dwalker@mvista.com>]

On Mon, 2006-10-09 at 00:35 +0200, Thomas Gleixner wrote:
> 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.

I think that code does belong there. Yes clocksources and timekeeping
are different. Which is the point of the patch set.

htimers is intrinsically connected to time keeping, but they aren't
housed in the same files. Just because one subsystem uses another
doesn't mean they shouldn't be organized/optimized/maintained on their
own.

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

Moving the code is a separation issue. I _could_ move it back, but you
haven't convinced me that it wins anything. In fact you've convinced me
that it would be a step back instead of forward.

> The maintainability of code has to weighed carefully against some
> obscure cylce savings.

It's not less maintainable now, or if it is your going to have to be a
lot more specific.

Daniel

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