Messages in this thread | | | Date | Wed, 27 Sep 2023 14:59:29 +0800 | From | Chen Yu <> | Subject | Re: [RFC PATCH 3/3] sched/fair: Add a per-shard overload flag |
| |
Hi Prateek,
On 2023-09-27 at 09:53:13 +0530, K Prateek Nayak wrote: > Hello David, > > Some more test results (although this might be slightly irrelevant with > next version around the corner) > > On 9/1/2023 12:41 AM, David Vernet wrote: > > On Thu, Aug 31, 2023 at 04:15:08PM +0530, K Prateek Nayak wrote: > > > -> With EEVDF > > o tl;dr > > - Same as what was observed without EEVDF but shared_runq shows > serious regression with multiple more variants of tbench and > netperf now. > > o Kernels > > eevdf : tip:sched/core at commit b41bbb33cf75 ("Merge branch 'sched/eevdf' into sched/core") > shared_runq : eevdf + correct time accounting with v3 of the series without any other changes > shared_runq_idle_check : shared_runq + move the rq->avg_idle check before peeking into the shared_runq > (the rd->overload check still remains below the shared_runq access) >
I did not see any obvious regression on a Sapphire Rapids server and it seems that the result on your platform suggests that C/S workload could be impacted by shared_runq. Meanwhile some individual workloads like HHVM in David's environment (no shared resource between tasks if I understand correctly) could benefit from shared_runq a lot. This makes me wonder if we can let shared_runq skip the C/S tasks. The question would be how to define C/S tasks. At first thought: A only wakes up B, and B only wakes up A, then they could be regarded as a pair of C/S (A->last_wakee == B && B->last_wakee == A && A->wakee_flips <= 1 && B->wakee_flips <= 1) But for netperf/tbench, this does not apply, because netperf client leverages kernel thread(workqueue) to wake up the netserver, that is A wakes up kthread T, then T wakes up B. Unless we have a chain, we can not detect this wakeup behavior.
thanks, Chenyu
| |