• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 2458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to change Linux 2.6.32 kernel tick rate for OMAP35x

Peter Thoeming
Intellectual 300 points
Other Parts Discussed in Thread: OMAP3525

I'd like to experiment with different tick rates for the Linux kernel on OMAP3525 HW with the hopes of improving what I believe are kernel-latency related issues.

I noticed in the code two param.h files related to "arm" or "plat-omap" that can assign HZ to some value.

In my .config file, I noticed these three config variables:

CONFIG_NO_HZ = y

CONFIG_OMAP_32K_TIMER_HZ=128

CONFIG_HZ=128

 

My questions are:

1. can the tick rate be increased beyond 128 Hz?

2. Which of those two CONFIG defines must I change to the rate I want or must I change them both to the same value and are there other variables that must be changed?

For example, I believe I must also set...

# CONFIG_NO_HZ is not set

...so that the other CONFIG statements are not ignored.

3. Must the value entered be a power of 2? (i.e. 128, 256, 512, etc.)?

4. To whomever answers this - have you experimented with different settings for the tick rate on this platform? If yes, how did you best measure/observe improvements or degradation in latency or throughput?

 

Thanks and best regards,

Peter

  • 0
    TI__Genius 15510 points

    To get finer resolution you could use a GP Timer. From the top-level linux source do 'make menuconfig' and select 'System Type' then 'TI OMAP Implementations' then 'System timer' and select 'Use mpu timer'.

    Steve K.

  • 0 in reply to Steve Kipisz
    Intellectual 300 points

    Thanks.

    I see what you're saying, but I don't fully appreciate the implications of changing that yet.

     

    So currently, we're using the default 32khz GPtimer as the source of tick interrupts by default.

     

    If I switch to using the mpu timer, are you saying that will have a different affect than simply changing the tick-rate value for "CONFIG_HZ"?

     

    If yes and I make the change, what types of differences should I expect (other than more power consumption)?

    Are there any other changes I must make to my .config or is selecting mpu timer enough?

    for example, should I remove tickless setting (CONFIG_NO_HZ is not set)?

    anything else?

     

    thanks in advance,

    Pete

  • 0 in reply to Peter Thoeming
    Intellectual 480 points

    CONFIG_HZ needs to match what the hardware is generating; changing CONFIG_HZ does not affect the actual clock rate. You need to change the clock source to a faster clock, ie using the MPU timer, then update CONFIG_HZ to reflect the new clock frequency.

    In other words, CONFIG_HZ is the symptom not the cause.

    -- Chip

     

  • 0 in reply to ChipD
    Intellectual 300 points

     

    I've edited my last response.

     

    I made the menuconfig change and it automatically assigns CONFIG_HZ to 100 when the MPU_TIMER is chosen.

    In most systems, the kernel is supposed to accept CONFIG_HZ as the value that should be programmed by the provided HW timer driver code into the timer.

    Likewise, the kernel code is suppose to assume that CONFIG_HZ is the rate at which the HW will truly send timer interrupts to the kernel.

     

    If you were to tell me that the MPU timer cannot support something other than 100Hz, then I would understand your comment that CONFIG_HZ is the symptom, not the cause.

    Otherwise, the MPU timer driver provided with the linux distro should be using CONFIG_HZ for initial board programming, not having to be re-written to support this standard configuration parameter.

     

    So, my new question becomes:

    Was the kernel provided by TI such that:

    A. if MPU_TIMER and the kernel configuration is set so that CONFIG_Hz = <any value> will be compiled/programmed into the MPU timer

    or

    B. if MPU_TIMER is set and CONFIG_HZ is set to any value other than 100Hz, one must modify/patch the kernel themselves because the kernel code was not provided by TI to support any value other than 100Hz and the user must modify the driver code to read CONFIG_HZ and program the value into the HW at board init time themselves