[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH] cpufreq_(ondemand|conservative) (round three)

Thanks for the patches. Here are some comments about _ondemand patches.

(1) 00_consistency patch
I think it is OK to do this for sampling_rate. But, we may have some
nasty races / corner conditions if we do this for up_threashold and
down_threshold. The race I am thinking about is: we check the new
down_value with old up_value and we may end up finally with
down_threshold greater than up_threshold.

(2) 01_ignore-nice
The idea to have this is good. Somehow I am thinking of some corner
cases here too.
If the prev_cpu_idle_up and prev_cpu_idle_down have unconditionally
include nice and total_ticks includes it conditionally, then we cannot
do the proper subtract and compare of idle times. Am I missing anything

(3) 02_check-rate-and-break-out
This looks good and ready to go.

(4) 03_sys_freq_step
Looks good. One minor issue. Policy->max can change at run time (when
a/c power and battery power). So behaviour might change if you
initialize freq_step once instead of checking 5% of max during each
switching. But, doing it this way should be OK too, as 5% is not a
strict number.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.029 / U:26.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site