Message-ID: <9fd2c37a05713c206dcbd5866f67ce779f315e9e.camel@gmx.de>
Subject: Re: [PATCH 10/10] sched/fair: Implement an EEVDF like policy
From:   Mike Galbraith <efault@gmx.de>
To:     Peter Zijlstra <peterz@infradead.org>, mingo@kernel.org,
        vincent.guittot@linaro.org
Cc:     linux-kernel@vger.kernel.org, juri.lelli@redhat.com,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, bristot@redhat.com, corbet@lwn.net,
        qyousef@layalina.io, chris.hyser@oracle.com,
        patrick.bellasi@matbug.net, pjt@google.com, pavel@ucw.cz,
        qperret@google.com, tim.c.chen@linux.intel.com, joshdon@google.com,
        timj@gnu.org, kprateek.nayak@amd.com, yu.c.chen@intel.com,
        youssefesmat@chromium.org, joel@joelfernandes.org
Date:   Wed, 08 Mar 2023 14:36:01 +0100
In-Reply-To: <bfbfbf041854e2cd1a8ed14e64081062e5d632d3.camel@gmx.de>
References: <20230306132521.968182689@infradead.org>
         <20230306141502.810909205@infradead.org>
         <bfbfbf041854e2cd1a8ed14e64081062e5d632d3.camel@gmx.de>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:khPj6n4i1q4=;GpJcHbgKEgv4BSiCUynICIsGSC/
 C7Zv44rywrwh40WmjXzhkU0hfayiRmnNmB74eLDgvUugl1oImgLC8oqjLuG7l4jOM82Byjkve
 J2Y9yog7AJxWRrdDYe/Vj7lY7Lb9qFfTzO93iLC+JralH623CnzhwUwd+7EeoDcFE2TyFo1q+
 5ILY5+BCJtv6a+XICb1ip9B+uhxhx4MPwonnripCTHs8j8pjp3IVaBP4ztyrok7McxLFbn66M
 cHkSK5CYIu6m33xx7otw0BpD+eqAblu9Z8YGcbBNVbdm+PtuaClfWClBSsmjyg5pGeLxOnZLe
 h1nEG+FDpVMuRjXSXI6JXiLKYY/fgGma22N36Y3RaiMbtZpUlbtVfs6f6GEpuYb8PYkwv9F4j
 n5QwtjoVym0oBGjDDgZCfKLdrRmv0EQ83sy6HF8o7KgzsJ+WkAysA/uqsspe1BLFNaP+wvP6A
 LT8WDv7nsjKtVsGO1a2KahMQ60xEy028btYCz55MRhf6zFRY/G4snIB2Dyrgr7jvm4S0i/PnE
 5QCf//j3QA0Z+MbLroDQDda+pVWuJvjjpwQ51NLPjE8MXLauryOlPs1Pfqbg+L0l7yGAroJds
 DOsJZCICRj7JLDY3G123T6VjCYHdnUm/KqHEl4D3eXM41OdTzbj+Fqt+faLq+KiH/IcGSMtRQ
 R/8Se5FS6ohjU/j8jKDh8BSgWvpS6rGFAgrcqRD7s7BQvEtdQQQ2tY9FoWFcc1qojyWnX/ubr
 thjGkfgASVlZe36oa2b+tpHafT9mqdXoHPFFIrYyG510IXBjimibi6qZoeFinwjqXh8CXpUR8
 FR+V95RUVA/9Y/j/XHe+8jcZ3qWXskjv0UBIXudG5tr2NmQL54eaxH/qOhTJUezqLiW9gmEzy
 0Gv95Lgj7ueICBo7BoXa7UpD1yo9+d/6gbnBfbaVzfmuLAkhl+kryilcoNpaSaP90lo1flJFy
 7tMBvDstYaQSPVDpmVSEzYkECzg=
Precedence: bulk

On Wed, 2023-03-08 at 09:39 +0100, Mike Galbraith wrote:
>
> Curiosity got the best of me...

Remember this little bugger, allegedly distilled from a real
application control thread starvation issue?

6.3.0.g8ca09d5-master
homer:/root # time taskset -c 3 starve
expecting to receive 10000000 signals

real    0m24.424s
user    0m4.468s
sys     0m18.957s

6.3.0.g8ca09d5-eevdf
homer:/root # time taskset -c 3 starve
expecting to receive 10000000 signals
zzzzzz
^C

real    15m24.115s
user    0m3.078s
sys     0m0.000s


#include <stdlib.h>
#include <stdio.h>
#include <signal.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/wait.h>

volatile unsigned long loop;

void handler(int n)
{
	if (loop > 0)
		--loop;
}

static int child(void)
{
	pid_t ppid =3D getppid();

	sleep(1);
	while (1)
		kill(ppid, SIGUSR1);
	return 0;
}

int main(int argc, char **argv)
{
	pid_t child_pid;
	int r;

	loop =3D argc > 1 ? strtoul(argv[1], NULL, 10) : 10000000;
	printf("expecting to receive %lu signals\n", loop);

	if ((child_pid =3D fork()) =3D=3D 0)
		exit(child());

	signal(SIGUSR1, handler);
	while (loop)
		sleep(1);
	r =3D kill(child_pid, SIGTERM);
	waitpid(child_pid, NULL, 0);
	return 0;
}