On 28 May 2014 19:37, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > Tomasz, > > On Thu, May 15, 2014 at 3:44 PM, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: >> Tomasz, >> >> On Thu, May 15, 2014 at 3:13 PM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: >>>> NOTE: if for some reason we need to keep the MCT around, we're >>>> definitely going to need to account for the fact that tweaking it >>>> affects the arch timer. ...and having the arch timer is really nice >>>> since: >>> >>> [Let me reorder the points below to make it easier to comment:] >>> >>>> * it's faster to access. >>>> * it is accessible from userspace for really fast access. >>> >>> Do you have some data on whether it is a significant difference, >>> especially considering real use cases? >> >> I know that Chrome makes _a lot_ of calls to gettimeofday() for >> profiling purposes, enough that it showed up on benchmarks. In fact, >> we made a change to the MCT to make accesses faster and there's a >> small mention of the benchmarking that was done at: >> >> https://chromium-review.googlesource.com/#/c/32190/ >> >> ...that change probably should be sent upstream, actually. >> >> I'll let Chirantan comment on how much faster arch timers were. >> ...and I think David Riley (also CCed now) may be able to comment on >> the benefits of userspace timers. >> >> >>>> * it implements the bits needed for udelay() to use it. >>> >>> Hmm, do you know what bits are those? On Exynos4 MCT is the only option >>> and it would be nice to let udelay() use it. >> >> Look for register_current_timer_delay(). It seems like we could do >> this for MCT, but I've never done the investigation because we were >> always planning to move to arch timers. ;) > > If you're planning to add support for MCT as a source for udelay, let > me know. It sounds like there's a chance that we won't be able to use > the ARCH timers on 5420 so we may be interested in these patches as > well. > > Also note that it appears that MCT upstream is also not used as a > scheduler clock. Perhaps you would want those patches, too? I think > Chirantan said that it will cause problems on systems that have both > MCT and arch timers though, since the system didn't like two scheduler > clocks to be registered (?). > > > In summary, we've got the following MCT patches proposed to go upstream: > > 1. MCT scheduler clock: <http://crosreview.com/56363> and > <http://crosreview.com/56364> > 2. Speed MCT access: <http://crosreview.com/56365>. I wonder if we > could also speed it up further with a 64-bit read. > 3. Use MCT for udelay: yet to be written. > > ...does someone want to claim the task of sending those things up? > > > Oh, actually it looks like (93bfb76 clocksource: exynos_mct: register > sched_clock callback) in linuxnext adds a partial version of the first > patch but isn't as complete as what's in our tree (it's missing the > KConfig change we have locally as well as the notrace so it probably > breaks ftrace?). Adding Vincent. Hi Doug, Thanks for adding me in the loop. The only difference i see are: -HAVE_SCHED_CLOCK which is no more needed -and the use of 32bit vs 64bit in the for-next -notrace is present in the for-next AFAICT Regards Vincent > > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |