Re: [PATCH 17/24] sched/fair: Implement delayed dequeue

Phil Auld
2024-11-01T13:38:35Z

On Fri, Nov 01, 2024 at 01:56:59PM +0100 Peter Zijlstra wrote:
> On Fri, Nov 01, 2024 at 08:47:15AM -0400, Phil Auld wrote:
>
> > This one is causing a 10-20% performance hit on our filesystem tests.
> >
> > On 6.12-rc5 (so with the latest follow ons) we get:
> >
> > with DELAY_DEQUEUE the bandwidth is 510 MB/s
> > with NO_DELAY_DEQUEUE the bandwidth is 590 MB/s
> >
> > The test is fio, something like this:
> >
> > taskset -c 1,2,3,4,5,6,7,8 fio --rw randwrite --bs 4k --runtime 1m --fsync 0 --iodepth 32 --direct 1 --ioengine libaio --numjobs 8 --size 30g --nrfiles 1 --loops 1 --name default --randrepeat 1 --time_based --group_reporting --directory /testfs
> >
> > In this case it's ext4, but I'm not sure it will be FS specific.
> >
> > I should have the machine and setup next week to poke further but I wanted
> > to mention it now just in case any one has an "aha" moment.
> >
> > It seems to only effect these FS loads. Other perf tests are not showing any
> > issues that I am aware of.
>
> There's a number of reports -- mostly it seems to be a case of excessive
> preemption hurting things.
>
> What happens if you use:
>
> schedtool -B -a 1-8 -e fio ....
>
>

Thanks for taking a look.

That makes the overall performance way worse:

DELAY_DEQUEUE - 146 MB/s
NO_DELAY_DEQUEUE - 156 MB/s

I guess that does make the difference between delay and nodelay
about half.

How is delay dequeue causing more preemption? Or is that more
for eevdf in general? We aren't seeing any issues there except
for the delay dequeue thing.

Cheers,
Phil

--