[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f51aa0683d0fc0dc046331691b4f18324548cf4.camel@gmx.de>
Date: Sat, 14 Oct 2023 10:08:00 +0200
From: Mike Galbraith <efault@....de>
To: Peter Zijlstra <peterz@...radead.org>,
Benjamin Segall <bsegall@...gle.com>
Cc: mingo@...nel.org, vincent.guittot@...aro.org,
linux-kernel@...r.kernel.org, juri.lelli@...hat.com,
dietmar.eggemann@....com, rostedt@...dmis.org, mgorman@...e.de,
bristot@...hat.com, corbet@....net, qyousef@...alina.io,
chris.hyser@...cle.com, patrick.bellasi@...bug.net, pjt@...gle.com,
pavel@....cz, qperret@...gle.com, tim.c.chen@...ux.intel.com,
joshdon@...gle.com, timj@....org, kprateek.nayak@....com,
yu.c.chen@...el.com, youssefesmat@...omium.org,
joel@...lfernandes.org, tglx@...utronix.de
Subject: Re: [PATCH 03/15] sched/fair: Add lag based placement
On Fri, 2023-10-13 at 18:35 +0200, Peter Zijlstra wrote:
> On Fri, Oct 13, 2023 at 12:34:28AM +0200, Peter Zijlstra wrote:
>
> > Right, so I do have this:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=sched/eevdf&id=344944e06f11da25b49328825ed15fedd63036d3
> >
> > That allows tasks to sleep away the lag -- with all the gnarly bits that
> > sleep time has. And it reliably fixes the above. However, it also
> > depresses a bunch of other stuff. Never a free lunch etc.
> >
> > It is so far the least horrible of the things I've tried.
>
> So the below is one I conceptually like more -- except I hate the code,
> nor does it work as well as the one linked above.
>
> (Mike, this isn't the same one you saw before -- it's been 'improved')
Still improves high frequency switchers vs hogs nicely.
tbench vs massive_intr
6.4.16-stable avg
2353.57 2311.77 2399.27 2354.87 1.00
6.4.16-eevdf avg
2037.93 2014.57 2026.84 2026.44 .86 1.00 DELAY_DEQUEUE v1
1893.53 1903.45 1851.57 1882.85 .79 .92 NO_DELAY_DEQUEUE
2193.33 2165.35 2201.82 2186.83 .92 1.07 DELAY_DEQUEUE v2
It's barely visible in mixed youtube vs compute in i7-4790 box,
squinting required, and completely invisible in dinky rpi4.
A clear win along with no harm to the mundane mix is a good start in my
book. Here's hoping canned benchmark bots don't grumble.
-Mike
Powered by blists - more mailing lists