On 18/03/2024 17:08, Rafael J. Wysocki wrote: > On Mon, Mar 18, 2024 at 5:40 PM Christian Loehle > <christian.loehle@xxxxxxx> wrote: >> >> On 18/03/2024 14:07, Rafael J. Wysocki wrote: >>> On Mon, Mar 4, 2024 at 9:17 PM Christian Loehle >>> <christian.loehle@xxxxxxx> wrote: >>>> >>>> The previous commit provides a new cpu_util_cfs_boost_io interface for >>>> schedutil which uses the io boosted utilization of the per-task >>>> tracking strategy. Schedutil iowait boosting is therefore no longer >>>> necessary so remove it. >>> >>> I'm wondering about the cases when schedutil is used without EAS. >>> >>> Are they still going to be handled as before after this change? >> >> Well they should still get boosted (under the new conditions) and according >> to my tests that does work. > > OK > >> Anything in particular you're worried about? > > It is not particularly clear to me how exactly the boost is taken into > account without EAS. So a quick rundown for now, I'll try to include something along the lines in future versions then, too. Every task_struct carries an io_boost_level in the range of [0..8] with it. The boost is in units of utilization (w.r.t SCHED_CAPACITY_SCALE, independent of CPU the task might be currently enqueued on). The boost is taken into account for: 1. sugov frequency selection with io_boost = cpu_util_io_boost(sg_cpu->cpu); util = max(util, io_boost); The io boost of all tasks enqueued on the rq will be max-aggregated with the util here. (See cfs_rq->io_boost_tasks). 2. Task placement, for EAS in feec(); Otherwise select_idle_sibling() / select_idle_capacity() to ensure the CPU satisfies the requested io_boost of the task to be enqueued. Determining the io_boost_level is a bit more involved than with sugov's implementation and happens in dequeue_io_boost(), hopefully that part is reasonably understandable from the code. Hope that helps. Kind Regards, Christian > >> So in terms of throughput I see similar results with EAS and CAS+sugov. >> I'm happy including numbers in the cover letter for future versions, too. >> So far my intuition was that nobody would care enough to include them >> (as long as it generally still works). > > Well, IMV clear understanding of the changes is more important.
