On 12/11/23 07:56, Lukasz Luba wrote:
On 12/10/23 20:51, Qais Yousef wrote:
On 12/08/23 10:05, Lukasz Luba wrote:
Hi Qais,
On 12/8/23 01:52, Qais Yousef wrote:
[snip]
@@ -6704,14 +6677,6 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
*/
util_est_enqueue(&rq->cfs, p);
- /*
- * If in_iowait is set, the code below may not trigger any cpufreq
- * utilization updates, so do it here explicitly with the IOWAIT flag
- * passed.
- */
- if (p->in_iowait)
- cpufreq_update_util(rq, SCHED_CPUFREQ_IOWAIT);
-
Why this io wait boost is considered as the $subject says 'aggressive'
calling?
This will trigger a frequency update along with the iowait boost. Did I miss
something?
Yes, it will change CPU freq and it was the main goal for this code
path. We have tests which check how that works on different memory
types.
Why do you want to remove it?
It seems you missed this hunk? I of course didn't remove it altogether if
that's what you mean :)
@@ -6772,6 +6737,8 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
enqueue_throttle:
assert_list_leaf_cfs_rq(rq);
+ cpufreq_update_util(rq, p->in_iowait ? SCHED_CPUFREQ_IOWAIT : 0);
+
hrtick_update(rq);
}
Did you run some tests (e.g. fio, gallery, etc) to check if you still
have a decent performance out some new ufs/nvme memories?
PCMark storage gives
before*: 29681
after: 30014