Re: [PATCH] U300 sched_clock implementation

[Paul Mundt]

On Tue, Jul 07, 2009 at 10:01:58AM +0200, Linus Walleij wrote:
> Adding in Paul M since it was his patch that was supposed to fix up a
> generic solution...
> 
> 2009/7/7 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>:
> > On Tue, Jun 02, 2009 at 11:00:12AM +0200, Peter Zijlstra wrote:
> >> I think its best if we continue with the patch Paul Mundt has been
> >> proposing.
> >
> > [added Tim Bird to CC]
> >
> > So what do we do? ?There's apparantly been zero movement on this for
> > over a month, and Tim Bird is reposting his patch adding __notrace
> > to ARMs existing sched_clock implementations.
> >
> > Given that it seems the generic approach has died a death, I suggest we
> > merge Linus' U300 patch, and get Tim to redo his patch to take account
> > of that, and apply both.
> >
> > Then, if the generic approach eventually happens, everything can then be
> > fixed up.
> >
> > Alternatively, if there is movement on the generic approach...
> >
> > Discuss.
> >
> 
> I would really like to see Pauls work finalized, it looked very promising,
> and I think there was actually a rough consensus about his last patch.
> But I guess that will be in the 2.6.32 merge window earliest?
> 
There was a consensus up until the point John noted that sched_clock()
can't wrap, so the generic approach is going to need a bit more work to
take the cycle shift and so on in to account. I've gotten momentarily
sidetracked with other things, but I'll post an updated version shortly.

Having said that, I don't see any reason why this should block progress
on the ARM side, once folks are happy with the generic version then most
of the implementations can be killed off, so a few more isn't going to
make much of a difference one way or the other.

The only reason I haven't done an SH-specific sched_clock() is because
none of our clocksources are architecture specific, and they all reside
in drivers/.
--
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/