I'll see what I can do.@Saber could you please divide all the cpu governors in your post as EAS governors and HMP governors ?
So that custom kernel devs can understand which governors to add or remove, especially for an EAS kernel...
Saber
I'll see what I can do.@Saber could you please divide all the cpu governors in your post as EAS governors and HMP governors ?
So that custom kernel devs can understand which governors to add or remove, especially for an EAS kernel...
Read this useful post by the OP:
The governor is the profile you select that will manage a great number of kernel related values, hotplugging can be a part of it. Someone smarter than me will correct that if I'm not (entirely) right ^_^TL;DR: Hotplug disables cores in order to save battery. However, it is old technology and now most people have their cores always on.
You should be able to find it under the hotplug tab in kernel auditor.
For difference between interactive and its x variant, please read the OP.
Finally after a lot of googling. Thank youRead this useful post by the OP:
The governor is the profile you select that will manage a great number of kernel related values, hotplugging can be a part of it. Someone smarter than me will correct that if I'm not (entirely) right ^_^
That post pretty much sums it all up.Read this useful post by the OP:
The governor is the profile you select that will manage a great number of kernel related values, hotplugging can be a part of it. Someone smarter than me will correct that if I'm not (entirely) right ^_^
Use apps to change govs - you fed root for that.Question (from a noob):
Does anyone know if there´s an option or a rom that has kinda like a built-in option to change governors? not the settings, just the governor per se; something like an option on the battery setting to select a governor, then reboot and work with that governor? (not dealing with the option, just changing the governor on the next reboot.
Also, what is more efficient: to go through each frequency or to go to pre-selected frequency?
I think that; battery wise; a pre-selected frequency would be faster but don´t know if would be efficient regarding the workload.
Seeing that you are running android 9 one ui u need to flash oreo gpu libs that come with moro 7.0.1 or you can search the BD nfe v4 thread for libs aloneHey, I have a little problem with my Galaxy S7 Edge. It is totally fluid only when playing it stutters something. When I set the CPU Governor to "Performance" everything is smooth. Here are the settings of my "Interactive" Governor. Does anyone have any tips what I should change here so that the games run smoothly? I tried to achieve something with the information in the Startpost, but did not get better. Thank you!
I dont think there is much you can do over that
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '95' it means that between the checking intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - Determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. T
v) down_differential - Indirectly calculates the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential).
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336.
vii) ignore_nice_load - this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
viii) sampling_rate_min -
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
3. SMARTASSV2i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up
ii) pump_up_step - No of scale up steps when load >= inc_cpu_load
iii) pump_down_step - No of scale down steps when load < inc_cpu_load
iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.
v) up_sample_time - Sampling time to scale cpu up. (Allowed values 10,000 to 50,000)
vi) down_sample_time - Sampling time to scale cpu down. (Allowed values 10,000 to 100,000)
i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
v) max_cpu_load - Same as up_threshold in other governors.
vi) min_cpu_load - Same as down_threshold in other governors.
vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
Ondemand and conservative have some tunables in common, but with a few extras:
i) freq_step - this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.
ii) down_threshold - same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
i) hispeed_freq - An intermediate "hi speed" at which to initially ramp when CPU load hits the value specified in go_hispeed_load. If load stays high for the amount of time specified in above_hispeed_delay, then speed may be bumped higher. Default is the maximum speed allowed by the policy at governor initialization time.
ii) go_hispeed_load - The CPU load at which to ramp to hispeed_freq. Default is 99%.
iii) min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. Default is 80000 uS.
iv) timer_rate - Sample rate for reevaluating CPU load when the CPU is not idle. A deferrable timer is used, such that the CPU will not be woken from idle to service this timer until something else needs to run. (The maximum time to allow deferring this timer when not running at
minimum speed is configurable via timer_slack.) Default is 20000 uS.
v) target_loads - CPU load values used to adjust speed to influence the current CPU load toward that value. In general, the lower the target load, the more often the governor will raise CPU speeds to bring load below the target. The format is a single target load, optionally followed by pairs of CPU speeds and CPU loads to target at or above those speeds. Colons can be used between the speeds and associated target loads for readability. For example:
85 1000000:90 1700000:99
targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. If speeds are specified these must appear in ascending order. Higher target load values are typically specified for higher speeds, that is, target load values also usually appear in an ascending order. The default is target load 90% for all speeds.
vi) above_highspeed_delay - When speed is at or above hispeed_freq, wait for this long before raising speed in response to continued high load. The format is a single delay value, optionally followed by pairs of CPU speeds and the delay to use at or above those speeds. Colons can be used between the speeds and associated delays for readability. For example:
80000 1300000:200000 1500000:40000
uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay 200000 uS is used until speed 1.5 GHz, at which speed (and above) delay 40000 uS is used. If speeds are specified these must appear in ascending order. Default is 20000 uS.
vii) timer_slack - Maximum additional time to defer handling the governor sampling timer beyond timer_rate when running at speeds above the minimum. For platforms that consume additional power at idle when CPUs are running at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed. For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed. A value of -1 means defer timers
indefinitely at all speeds. Default is 80000 uS.
viii) boost - If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual. Default is zero.
ix) boostpulse - On each write, immediately boost speed of all CPUs to hispeed_freq for at least the period of time specified by boostpulse_duration, after which speeds are allowed to drop below hispeed_freq according to load as usual.
x) boostpulse_duration - Length of time to hold CPU speed at hispeed_freq on a write to boostpulse, before allowing speed to drop according to load as usual. Default is 80000 uS.
Has some tunables in common with the generic version but with a few extras:
i) Sync_freq Feature - This feature will cause a CPU frequency to stay above a particularvalue sync_freq) if certain conditions (determined by the two nodes up_threshold_any_cpu_freq and up_threshold_any_cpu_load) are satisfied
ii) Sync_freq - Only when both of the above conditions are satisfied will the CPU not drop below this frequency value. The higher this value, the higher the frequency to jump will be when the above conditions are satisfied.
iii) Up_threshold_any_cpu_freq - If the maximum frequency across all the CPUs is higher than or equal to this frequency value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.
iv) Up_threshold_any_cpu_load - If the maximum load across all the CPUs is higher than or equal to this load value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.
v) up_threshold_multi_core - When the up_threshold_multi_core is crossed, the cpu is ramped up to optimal_freq.
vi) optimal_freq - When more than one CPU is online and if up_threshold_multi_core has exceeded, the governor will ramp up the CPU to this frequency. This value should be less than your device's max CPU frequency.
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
cpu_up_rate - No of samples to evaluate load to scale CPU frequency up. Increasing this value will increase the time spent on a frequency.
cpu_down_rate - No of samples to evaluate load to scale CPU frequency down. Increasing this value will increase the time spent on a frequency
inc_cpu_load_at_min_freq - This threshold is used as up threshold while sampling at frequencies is less than freq_for_responsiveness.
inc_cpu_load - The frequency at which governor scales CPU up.
dec_cpu_load - The frequency at which governor scales CPU down.
sampling_rate_sleep_multiplier -> sampling rate multiplier on early suspend (possible values 1 or 2, default: 2)
up_threshold_sleep -> up threshold on early suspend (possible range from above 'down_threshold_sleep' up to 100, default: 90)
down_threshold_sleep -> down threshold on early suspend (possible range from 11 to 'under up_threshold_sleep', default: 44)
smooth_up -> smooth up scaling when screen is on (possible range from 1 to 100, default: 100)
smooth_up_sleep -> smooth up scaling on early suspend (possible range from 1 to 100, default: 100)
up_threshold_hotplug x -> hotplug threshold for cpu core x (0 disable core, possible range from 'down_threshold' up to 100, default: 68)
down_threshold_hotplug x -> hotplug threshold for cpu core x (possible range from 1 to under 'up_threshold', default: 55)
block_down_multiplier_hotplug x -> block down multiplier for core x
block_up_multiplier_hotplug x -> block up multiplier for core x
sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole sampling rate or the value for stock 'down skip' functionality which influences only the down scaling mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)
freq_limit_sleep-> limit freqency at early suspend (possible values 0 disable limit, 200-1600, default: 0)
freq_limit -> limit freqency at awake (possible values 0 disable limit, 200-1600, default: 0)
scaling_proportional -> if enabled load-proportional frequencies will be calculated in parallel and will be used in decision for next freq step. after a comparison between normal system table step and proportional step the lowest of these two frequencies will be used for next freq step in both directions. (0 to disable, any value above 0 to enable)
scaling_block_temp -> CPU temperature threshold from where governors freq 'holding' should start. if the given temperature (if CPU temp reading is enabled) is reached the frequency used in tunable 'scaling_block_freq' will be forced targeted and scaling stays on this freq till the temperature is under the threshold again. at the same time hotplugging up work is blocked so in this throttling phase offline cores are staying offline even if the hotplug up thresholds are reached (0 to disable, values between 30 and 80 in °C)
scaling_up_block_cycles -> similar to scaling fastdown but here for a slowdown of up scaling
scaling_up_block_freq -> similar to scaling fastdown but here for a slowdown of up scaling
fast_scaling_up -> Number of scaling jumps only for upscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_down -> Number of scaling jumps only for downscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_sleep_up -> Number of scaling jumps only for upscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_sleep_down -> Number of scaling jumps only for downscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.
disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to enable it, default 0)
auto_adjust_freq_thresholds -> if enabled all freq thresholds used by the governor will be adjusted accordingly to the new scaling max policy. in particular the thresholds will be increased/decreased by the actual changed max freq step if that change will undercut/exceed the actual min/max freq policy it will stop at the max possible frequency step before undercutting/exceeding min/max freq policy (0 to disable, any value above 0 to enable)
early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 1 to 100, default 50) little example for understanding: when the load rises up in one big 50% step then the frequency will be scaled up immediately instead of wating till up_threshold is reached.
early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)
grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold for switching internally (tuneables are staying at set values!) sampling_rate_sleep_multiplier to 2 and fast_scaling to 2 (possible values from 1 to 100, default is 35)
hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging. possible values 0 disable, any values above 0 (default is 0)
hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)
sampling_rate_current -> read only and shows currently active sampling rate
sampling_rate_idle -> sampling rate which should be used at 'idle times' (possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)
sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa (possible values are any value and 0 to disable delay, default is 0)
sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active (possible values 1 to 100, 0 to disable function, default is 0)
scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that function, default is 0)
scaling_block_freq -> frequency at and above the blocking should be active (possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)
scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles (possible value are 1 to 100, 0 to disable gradient counting)
scaling_block_force_down -> multiplier for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down) therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling and use only scaling up blocks)
profile_number ->
1) for Default (set governor defaults)
2) for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3) for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4) for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5) for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
6) for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7) for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
8) for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9) for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10) for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
11) for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)
scaling_fastdown_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_fastdown_up_threshold -> once the above frequency threshold has been met, this will become the new up_threshold until we fall below the scaling_fastdown_freq again. (range from over fastdown_down_threshold to 100, default is 95)
scaling_fastdown_down_threshold -> once the above frequency threshold has been met, this will become the new down_threshold until we fall below the scaling_fastdown_freq again. (range from 11 to under fastdown_up_threshold, default is 90)
scaling_responsiveness_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_responsiveness_up_threshold -> the up_threshold that will take effect if scaling_responsiveness_freq is set (range from 11 to 100, default is 30)
hotplug_engage_freq -> will not bring any cores online until this frequency is met or exceeded
(0 to disable, all possible system frequencies, default is 0)
music_max_freq -> maximum frequency for CPU when governor is on music mode
music_min_cores -> minimum CPU cores used when governor is on music mode
music_min_freq -> minimum frequency for CPU when governor is on music mode
afs_threshold 1,2,3 -> Auto fast scaling for step one to three respectively (range from 1 to 100)
boost_duration - how long you want the governor to boost your CPU in seconds.
down_rate - The minimum amount of time in nsecs to spend at a frequency before we can ramp down. Notice we ignore this when we are above the ideal frequency.
io_is_busy - Consider if IO is busy
max_cpu_load - CPU freq will be increased if measured load > max_cpu_load
min_cpu_load - CPU freq will be decreased if measured load < min_cpu_load
ramp_up_during_boost - should ramp_up steps during boost be possible
ramp_up_step - Frequency delta when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal freqeuncy we always ramp up to the ideal freq.
Touch_poke_freq - Also known as the touch boost frequency. This is the frequency that you CPU jumps to when touching screen.
fifo_batch: This parameter controls the maximum number of requests per batch.It tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behavior). Increasing fifo_batch generally improves throughput, at the cost of latency variation. The default is 16.
front_merges: A request that enters the scheduler is possibly contiguous to a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. Hence it’s called either a back merge candidate or a front merge candidate. Typically back merges are much more common than front merges. You can set this tunable to 0 if you know your workload will never generate front merges. Otherwise leave it at its default value 1.
read_expire: In all 3 schedulers, there is some form of deadline to service each Read Request. The focus is read latencies. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of milliseconds. The default value is 500 ms.
write_expire: Similar to Read_Expire, this applies only to the Write Requests. The default value is 5000 ms.
writes_starved: Typically more attention is given to the Read requests over write requests. But this can’t go on forever. So after the expiry of this value, some of the pending write requests get the same priority as the Reads. Default value is 1.
This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
add_random
In some cases, the overhead of I/O events contributing to the entropy pool for /dev/random is measurable. In such cases, it may be desirable to set this value to 0.
nomerges
This tunable is primarily a debugging aid. Most workloads benefit from request merging (even on faster storage such as SSDs). In some cases, however, it is desirable to disable merging, such as when you want to see how many IOPS a storage back-end can process without disabling read-ahead or performing random I/O.
nr_requests
If you have a latency-sensitive application, then you should consider lowering the value of nr_requests in your request queue and limiting the command queue depth on the storage to a low number (even as low as 1), so that writeback I/O cannot allocate all of the available request descriptors and fill up the device queue with write I/O. Once nr_requests have been allocated, all other processes attempting to perform I/O will be put to sleep to wait for requests to become available. This makes things more fair, as the requests are then distributed in a round-robin fashion (instead of letting one process consume them all in rapid succession).
optimal_io_size
In some circumstances, the underlying storage will report an optimal I/O size. This is most common in hardware and software RAID, where the optimal I/O size is the stripe size. If this value is reported, applications should issue I/O aligned to and in multiples of the optimal I/O size whenever possible.
rotational
Traditional hard disks have been rotational (made up of spinning platters). SSDs, however, are not. Most SSDs will advertise this properly. If, however, you come across a device that does not advertise this flag properly, it may be necessary to set rotational to 0 manually; when rotational is disabled, the I/O elevator does not use logic that is meant to reduce seeks, since there is little penalty for seek operations on non-rotational media.
rq_affinity
I/O completions can be processed on a different CPU from the one that issued the I/O. Setting rq_affinity to 1 causes the kernel to deliver completions to the CPU on which the I/O was issued. This can improve CPU data caching effectiveness.
back_seek_max: The scheduler tries to guess that the next request for access requires going backwards from current position on the Disc. Given that such going back can be time consuming. So in anticipation, may move back on the disc prior to the next request. This setting, given in Kb, determines the max distance to go back. Default value is set to 16 Kb.
Do note that in a cellphone or tablet, the storage is actually Flash Memory technology. There is Disk head to be re-positioned. As such this is not that effective as backward reads are not that bad.
back_seek_penalty: This parameter is used to compute the cost of backward seeking. If the backward distance of a request is just 1 from a front request, then the seeking cost of the two requests is considered equivalent and the scheduler will not bias toward one or the other. This parameter defaults to 2 so if the distance is only 1/2 of the forward distance, CFQ will consider the backward request to be close enough to the current head location to be “close”. Therefore it will consider it as a forward request.
fifo_expire_async & fifo_expire_sync : This particular parameter is used to set the timeout of asynchronous requests. CFQ maintains a fifo (first-in, first-out) list to manage timeout requests. The default value is 250 ms. A smaller value means the timeout is considered much more quickly than a larger value. Similarly, fifo_expire_sync applies to the Synchronous requests. The default is 125 ms.
group_idle: If this is set, CFQ will idle before executing the last process issuing I/O in a cgroup. This should be set to 1 along with using proportional weight I/O cgroups and setting slice_idle to 0 as Flash memory is a fast storage mechanism.
group_isolation: If set (to 1), there is a stronger isolation between groups at the expense of throughput. If disabled, Scheduler is biased towards sequential requests. When enabled group isolation provides balance for both sequential and random workloads. The default value is 0 (disabled).
low_latency: When set (to 1), CFQ attempts to build a backlog of write requests. It will give a maximum wait time of 300 ms for each process issuing I/O on a device. This offers fairness over throughput. When disabled (set to 0), it will ignore target latency, allowing each process in the system to get a full time slice. This is enabled by default.
Quantum: This option controls the maximum number of requests being processed at a time. The default value is 8. Increasing the value can improve performance; the latency of some I/O may be increased due to more requests being buffered inside the storage.
slice_async: This parameter controls Maximum number of asynchronous requests at a time. The default value is set to 40 ms.
slice_idle: When a task has no more requests to submit in its time slice, the scheduler waits for a while before scheduling the next thread to improve locality. The default value is 0 indicating no idling. However, a zero value increases the overall number of seeks. Hence a Non-zero number may be beneficial.
slice_sync: This setting determines the time slice allotted to a process I/O. The default is 100 ms.
timeout_sync & timeout_async: These parameters determine maximum disk time given to a task, respectively for synchronous and asynchronous queues. It allows the user to control the latencies imposed by the scheduler.
max_budget: This determines, how much of the queue request is serviced based on number of sectors on disc. A larger value increases the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. Consequence is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning
max_budget_async_rq: This setting determines number of async queues served for a maximum number of requests, before selecting a new queue.
low_latency: When this is set to 1 (default is 1), interactive and soft real-time applications experience a lower latency.
hp_read_quantum: Dispatch quantum for the high priority READ queue. Default: 10
rp_read_quantum: Dispatch quantum for the regular priority READ queue. Default: 100
hp_swrite_quantum: Dispatch quantum for the high priority Synchronous WRITE queue. Default: 1
rp_swrite_quantum: Dispatch quantum for the regular priority Synchronous WRITE queue. Default: 1
rp_write_quantum: Dispatch quantum for the regular priority WRITE queue. Default: 1
lp_read_quantum: Dispatch quantum for the low priority READ queue. Default: 1
lp_swrite_quantum: Dispatch quantum for the low priority Synchronous WRITE queue. Default: 1
read_idle: Determines length of idle on read queue in Msec (in case idling is enabled on that queue). Default: 5ms
read_idle_freq: Determines the frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests. Default: 5ms
rev_penalty: Penalty for reversing head direction.
fifo_batch: Number of requests to issue before checking for expired requests.
sync_expire: Deadline for synchronous requests.
async_expire: Deadline for asynchronous requests.