Re: [tip: sched/core] sched/eevdf: Curb wakeup-preemption
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip: sched/core] sched/eevdf: Curb wakeup-preemption
- From: Mike Galbraith <efault@xxxxxx>
- Date: Tue, 22 Aug 2023 08:09:49 +0200
- Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-tip-commits@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, Chen Yu <yu.c.chen@xxxxxxxxx>, Gautham Shenoy <gautham.shenoy@xxxxxxx>
- In-reply-to: <f0859f35-39ec-e5dc-b77a-79162516de31@amd.com>
- References: <20230816134059.GC982867@hirez.programming.kicks-ass.net> <169228500414.27769.13366308319134164264.tip-bot2@tip-bot2> <21f3d376-17d6-8fb6-5f35-507ea931c0d3@amd.com> <02f6a15f094adb3c8d9957b031941d6bd10c2e43.camel@gmx.de> <f0859f35-39ec-e5dc-b77a-79162516de31@amd.com>
- Ui-outboundreport: notjunk:1;M01:P0:mOKMarcG88Y=;iHZioWDAFWTc7bGQQ2B79P4B0HA nXH7jRLD7+UnTe0M2FVZELkzHppqJrT/HOUw8V0Y7FvhxgOaOrjWbFN9o7XqCLChNeG9q4IpN OaKiKugh5cyERGP+Yh9suxX1Epp1KlNYaNs/Iq5ZjYdvRyPO2DZFZxoTWPnx3FpXI4UGEXbWx 3brbrQPZcSGKgv+/z+HTAxNQej74kYxovHmbs9PghEEwM7HezxuE36DxZBz5GI+pgHgTvJB6Y xLESEBLbWuZq0GWqU7jUZmrPmtJ9E2puJJt5PzAbdsp8L8aRS4HY9eCtwOm41S1zs7u3re+vQ Jox0Wi3eAj2O84dd7rini6/v3eFF6IrOoddBd6f8uKFfBBg2/PmKUPq0/IAUXB//YsrgAJ7jW 93OuUYpHn741wmdhq/phz4HEinQ90k71jIcqXPCTT4DzArh6gmN5uc5LQ9EjJFlrEQ/5z7AZ3 FXP/bjmc5uVaJC9mIyR/wBmIubZmMU4yN3YfyJJCUvoCgYEtn8MQXwRP7ouK78QUoOTJMshOF txTqxLRbEPPT4hIDWzV1sWxzfTJVEazqEQU6N2dpY9Vl8CtrSg+7NaxkjOO3vgAJm83zIcXAh +Yvu/xp42FJ1LDLQSoCWk224/b1YHFINQ+1ZAv+5zuDCI+CVVjqoNJn0gIdXvPz98o0W/JQOu O9xyxMmzXLZCS/f1zrn8rRkqgUnwfQYiVXxIB0JrlrhNuXgrDNt+LdjVfNLCI8J2afsOLwTOT PlwRYTmrUMO+zGkO8E3xUEawnTSAd46KxQ4VymxXFMrqe0YwRM2UKqztRuf/UxENN8BwU1P8i jiM/JK2FFOMklPQvzEmIFvTdEe5J1K2o2uRzeYi3ntM4Gl35VSm8bwDaeloyUJvctq8Hw/zSf eY4TqCmRYrv0qfeCd+Uq4846fqCLsYXP0daqYT6l4hEaLUflRoh/1iu9owzdilhds+Bnw4JiW 2s4qV4NryTzPeSRelZNWk6IttxE=
- User-agent: Evolution 3.42.4
On Tue, 2023-08-22 at 08:33 +0530, K Prateek Nayak wrote:
> Hello Mike,
Greetings!
> > FWIW, there are more tbench shards lying behind EEVDF than in front.
> >
> > tbench 8 on old i7-4790 box
> > 4.4.302 4024
> > 6.4.11 3668
> > 6.4.11-eevdf 3522
> >
>
> I agree, but on servers, tbench has been useful to identify a variety of
> issues [1][2][3] and I believe it is better to pick some shards up than
> leave them lying around for others to step on :)
Absolutely, but in this case it isn't due to various overheads wiggling
about and/or bitrot, everything's identical except the scheduler, and
its overhead essentially is too.
taskset -c 3 pipe-test
6.4.11 1.420033 usecs/loop -- avg 1.420033 1408.4 KHz
6.4.11-eevdf 1.413024 usecs/loop -- avg 1.413024 1415.4 KHz
Methinks these shards are due to tbench simply being one of those
things that happens to like the CFS notion of short term fairness a bit
better than the EEVDF notion, ie are inevitable fallout tied to the
very thing that makes EEVDF service less spiky that CFS, and thus will
be difficult to sweep up.
Too bad I didn't save Peter's test hack to make EEVDF use the same
notion of fair (not a keeper) as I think that would likely prove it.
-Mike
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]