How to use a different sched_clock() for ftrace on omap?

How to use a different sched_clock() for ftrace on omap?

[Tim Bird]

Hi all,

I've worked up a replacement sched_clock for ftrace on my omap platform.
The current sched_clock, based on the 32K timer, has low resolution and
doesn't provide very useful results.

Unfortunately, I'm not sure the best way to use my special one, in place
of a common one in arch/arm/plat-omap/common.c

Here's a patch:

---
 arch/arm/mach-omap1/time.c  |    9 +++++++++
 arch/arm/plat-omap/common.c |    2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -212,6 +212,15 @@ static struct clocksource clocksource_mp
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };

+unsigned long long notrace sched_clock(void)
+{
+	unsigned long long ret;
+
+	ret = (unsigned long long) ~omap_mpu_timer_read(1);
+	ret = (ret * clocksource_mpu.mult_orig) >>clocksource_mpu.shift;
+	return ret;
+}
+
 static void __init omap_init_clocksource(unsigned long rate)
 {
 	static char err[] __initdata = KERN_ERR
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -203,7 +203,7 @@ static struct clocksource clocksource_32
  * Returns current time from boot in nsecs. It's OK for this to wrap
  * around for now, as it's just a relative time stamp.
  */
-unsigned long long notrace sched_clock(void)
+__attribute__((weak)) unsigned long long notrace sched_clock_old(void)
 {
 	unsigned long long ret;


Obviously, renaming the common sched_clock() to sched_clock_old() is
a hack.

I thought the __attribute__ ((weak)) would be enough to have the
sched_clock() in common.c get out of the way, and allow my board-specific
sched_clock() to be used.  But that didn't work.  What is the recommended
way to specify a board-specific function at compile time?

Thanks,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: How to use a different sched_clock() for ftrace on omap?

[Ryan Mallon]

Tim Bird wrote:
> Hi all,
> 
> I've worked up a replacement sched_clock for ftrace on my omap platform.
> The current sched_clock, based on the 32K timer, has low resolution and
> doesn't provide very useful results.
> 
> Unfortunately, I'm not sure the best way to use my special one, in place
> of a common one in arch/arm/plat-omap/common.c
> 
> I thought the __attribute__ ((weak)) would be enough to have the
> sched_clock() in common.c get out of the way, and allow my board-specific
> sched_clock() to be used.  But that didn't work. 

Not sure that will work correctly since sched_clock in kernel/sched.c is
already defined as weak. If you have two weak versions of a function I
think the one which gets used is based on link order (if your board's
sched_clock is not being used).

> What is the recommended
> way to specify a board-specific function at compile time?

You could look at arch/x86/kernel/tsc_32.c, I think it does what you
want by using the function called native_sched_clock for the default
sched_clock implementation and using the alias attribute if no board
specific implementation is given, ie:

#ifdef CONFIG_SOME_BOARD
unsigned long long sched_clock(void)
{
	some_board_sched_clock();
}
#else
unsigned long long sched_clock(void)
	__attribute__((alias("native_sched_clock")));
#endif

You could make it more generic by have some_board_sched_clock be a
#define (__board_sched_clock or something), so if a board defines it
(will need to be in a platform wide header) then you use that, otherwise
you use native_sched_clock.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

       Ryan Mallon                              Unit 5, Amuri Park
       Phone: +64 3 3779127                     404 Barbadoes St
       Fax:   +64 3 3779135                     PO Box 13 889
       Email: ryan@bluewatersys.com             Christchurch, 8013
       Web:   http://www.bluewatersys.com       New Zealand
       Freecall Australia  1800 148 751         USA 1800 261 2934

Re: How to use a different sched_clock() for ftrace on omap?

[Ingo Molnar]

* Tim Bird <tim.bird@am.sony.com> wrote:

> Hi all,
> 
> I've worked up a replacement sched_clock for ftrace on my omap 
> platform. The current sched_clock, based on the 32K timer, has low 
> resolution and doesn't provide very useful results.

hm, why dont you replace the real sched_clock() with it? High 
resolution sched_clock() gives (much!) better scheduling, better 
fairness, etc.

	Ingo

Re: How to use a different sched_clock() for ftrace on omap?

[Steven Rostedt]

On Thu, 7 May 2009, Ingo Molnar wrote:

> 
> * Tim Bird <tim.bird@am.sony.com> wrote:
> 
> > Hi all,
> > 
> > I've worked up a replacement sched_clock for ftrace on my omap 
> > platform. The current sched_clock, based on the 32K timer, has low 
> > resolution and doesn't provide very useful results.
> 
> hm, why dont you replace the real sched_clock() with it? High 
> resolution sched_clock() gives (much!) better scheduling, better 
> fairness, etc.

Probably because it is board specific, that he can not replace it. But I 
think something like Ryan's idea would be good. Instead of aliasing, just 
make another weak symbol.


unsigned long long __attribute__((weak)) board_sched_clock(void)
{
	[ original sched_clock code ]
}

unsigned long long sched_clock(void)
{
	return board_sched_clock();
}



Then Tim could define a "board_sched_clock" that would be used when that 
board is active.

-- Steve

Re: How to use a different sched_clock() for ftrace on omap?

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 7 May 2009, Ingo Molnar wrote:
> 
> > 
> > * Tim Bird <tim.bird@am.sony.com> wrote:
> > 
> > > Hi all,
> > > 
> > > I've worked up a replacement sched_clock for ftrace on my omap 
> > > platform. The current sched_clock, based on the 32K timer, has low 
> > > resolution and doesn't provide very useful results.
> > 
> > hm, why dont you replace the real sched_clock() with it? High 
> > resolution sched_clock() gives (much!) better scheduling, better 
> > fairness, etc.
> 
> Probably because it is board specific, that he can not replace it. But I 
> think something like Ryan's idea would be good. Instead of aliasing, just 
> make another weak symbol.
> 
> 
> unsigned long long __attribute__((weak)) board_sched_clock(void)
> {
> 	[ original sched_clock code ]
> }
> 
> unsigned long long sched_clock(void)
> {
> 	return board_sched_clock();
> }
> 
> Then Tim could define a "board_sched_clock" that would be used 
> when that board is active.

that sounds good. Weak aliases are now generally supported in Linux, 
we excluded that one broken GCC version that messed them up.

	Ingo

Re: How to use a different sched_clock() for ftrace on omap?

[Kevin Hilman]

Tim Bird <tim.bird@am.sony.com> writes:

> Hi all,
>
> I've worked up a replacement sched_clock for ftrace on my omap platform.
> The current sched_clock, based on the 32K timer, has low resolution and
> doesn't provide very useful results.
>
> Unfortunately, I'm not sure the best way to use my special one, in place
> of a common one in arch/arm/plat-omap/common.c

Hi Tim,

If you're comiling mach-omap1/time.c than you've enabled the
higher-resolution MPU timer with CONFIG_OMAP_MPU_TIMER, right?

In that case, you could make the one in plat-omap/common.c inside and
#ifndef CONFIG_OMAP_MPU_TIMER and put the new one in the MPU_TIMER
code.

To be complete, you should add the same to the mach-omap2/timer-gp.c
as well.

Kevin

> Here's a patch:
>
> ---
>  arch/arm/mach-omap1/time.c  |    9 +++++++++
>  arch/arm/plat-omap/common.c |    2 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> --- a/arch/arm/mach-omap1/time.c
> +++ b/arch/arm/mach-omap1/time.c
> @@ -212,6 +212,15 @@ static struct clocksource clocksource_mp
>  	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
>  };
>
> +unsigned long long notrace sched_clock(void)
> +{
> +	unsigned long long ret;
> +
> +	ret = (unsigned long long) ~omap_mpu_timer_read(1);
> +	ret = (ret * clocksource_mpu.mult_orig) >>clocksource_mpu.shift;
> +	return ret;
> +}
> +
>  static void __init omap_init_clocksource(unsigned long rate)
>  {
>  	static char err[] __initdata = KERN_ERR
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -203,7 +203,7 @@ static struct clocksource clocksource_32
>   * Returns current time from boot in nsecs. It's OK for this to wrap
>   * around for now, as it's just a relative time stamp.
>   */
> -unsigned long long notrace sched_clock(void)
> +__attribute__((weak)) unsigned long long notrace sched_clock_old(void)
>  {
>  	unsigned long long ret;
>
>
> Obviously, renaming the common sched_clock() to sched_clock_old() is
> a hack.
>
> I thought the __attribute__ ((weak)) would be enough to have the
> sched_clock() in common.c get out of the way, and allow my board-specific
> sched_clock() to be used.  But that didn't work.  What is the recommended
> way to specify a board-specific function at compile time?
>
> Thanks,
>  -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
>
> --
> 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/

Re: How to use a different sched_clock() for ftrace on omap?

[Tim Bird]

Kevin Hilman wrote:
> Tim Bird <tim.bird@am.sony.com> writes:
> 
>> Hi all,
>>
>> I've worked up a replacement sched_clock for ftrace on my omap platform.
>> The current sched_clock, based on the 32K timer, has low resolution and
>> doesn't provide very useful results.
>>
>> Unfortunately, I'm not sure the best way to use my special one, in place
>> of a common one in arch/arm/plat-omap/common.c
> 
> Hi Tim,
> 
> If you're comiling mach-omap1/time.c than you've enabled the
> higher-resolution MPU timer with CONFIG_OMAP_MPU_TIMER, right?

Yes.

> In that case, you could make the one in plat-omap/common.c inside and
> #ifndef CONFIG_OMAP_MPU_TIMER and put the new one in the MPU_TIMER
> code.
> 
> To be complete, you should add the same to the mach-omap2/timer-gp.c
> as well.

I was trying to avoid using #ifdefs, but maybe in this case it
makes sense.  There are tradeoffs in using the different timers
(nicely described in plat-omap/Kconfig help entries), so IMHO it
would be good to make this a config preference.

I'll work up a patch in this style and send it along.
 -- Tim


=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: How to use a different sched_clock() for ftrace on omap?

[Kevin Hilman]

Tim Bird <tim.bird@am.sony.com> writes:

> Kevin Hilman wrote:
>> Tim Bird <tim.bird@am.sony.com> writes:
>> 
>>> Hi all,
>>>
>>> I've worked up a replacement sched_clock for ftrace on my omap platform.
>>> The current sched_clock, based on the 32K timer, has low resolution and
>>> doesn't provide very useful results.
>>>
>>> Unfortunately, I'm not sure the best way to use my special one, in place
>>> of a common one in arch/arm/plat-omap/common.c
>> 
>> Hi Tim,
>> 
>> If you're comiling mach-omap1/time.c than you've enabled the
>> higher-resolution MPU timer with CONFIG_OMAP_MPU_TIMER, right?
>
> Yes.
>
>> In that case, you could make the one in plat-omap/common.c inside and
>> #ifndef CONFIG_OMAP_MPU_TIMER and put the new one in the MPU_TIMER
>> code.
>> 
>> To be complete, you should add the same to the mach-omap2/timer-gp.c
>> as well.
>
> I was trying to avoid using #ifdefs, but maybe in this case it
> makes sense.  There are tradeoffs in using the different timers
> (nicely described in plat-omap/Kconfig help entries), so IMHO it
> would be good to make this a config preference.

Yes, we have PM reasons for wanting to choose between the different
timers.

> I'll work up a patch in this style and send it along.

OK, please send it to linux-omap as well.

On a related note, and not your problem here but something that would
be nice to see is the default sched_clock implementation using the
clocksource instead of jiffies.

Then, platform code just registers its preferred clocksource and
sched_clock() gets the same resolution as the clocksource.  Not sure
how yet to handle clocksources being added and removed though...

Kevin