Received-SPF: pass (google.com: domain of linux-kernel+bounces-173370-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <9c360c0d337b124c71095f06889d1c69279a7c06.camel@gmx.de>
Subject: Re: [RFC][PATCH 10/10] sched/eevdf: Use sched_attr::sched_runtime
 to set request/slice suggestion
From: Mike Galbraith <efault@gmx.de>
To: Chen Yu <yu.c.chen@intel.com>, Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, 
 dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
 mgorman@suse.de,  bristot@redhat.com, vschneid@redhat.com,
 linux-kernel@vger.kernel.org,  kprateek.nayak@amd.com,
 wuyun.abel@bytedance.com, tglx@linutronix.de,  tim.c.chen@intel.com,
 yu.c.chen.y@gmail.com
Date: Wed, 08 May 2024 15:52:32 +0200
In-Reply-To: <ZjpFruUiBiNi6VSO@chenyu5-mobl2>
References: <20240405102754.435410987@infradead.org>
	 <20240405110010.934104715@infradead.org> <ZjpFruUiBiNi6VSO@chenyu5-mobl2>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:Gw5PYY1ZB6A=;glpYNK6WATXwgcaY+mtwtEf9zcF
 dbiCPUTF4MqtFS5zKu+feso2oXsKh4BAdc74sv8kN4qsRgK0OLWOusV1KCqONK5LnLRfJY2gX
 LdAsYXHfW2V3RkCBAPZ1wcW+m+XkODqWR1VVhYYWelIy9+PA+W9sxfmg7XdntzP/4T35NRUln
 IGg2t0bQIewyMEbB2QgbjcLAgz30+1alN+UNw3yr/JPgBLb6h3XVJhjO+7+9kPYY+LUB5CJZH
 NnwNF0eLY1kglS27cAxaR/y8CuWzh0BHZGnGta3PaSykI8AmOCBapswR9Rea86i4sMwNCqUtO
 lK03uX2P8jmXl/c6vNfAJCDcGGI2IJMINn95JSvSDk8p0LmZq75dwjNFOVU6ut266BQ2YYTdF
 gkcD+qv+iubZyt8FZCK8Gn2O2X7CKpuG2L/fAjAulAdnnTf0YiBL6puQMbWi5gMZYWhVNoY3Z
 XJSrTp4R80edO/od2tIkhKi8CxxXnopUu4eu1GPtv39Yzz8FLaeGNaPdNjJlPLKn/yZ8Wnvyf
 kU/Wwys87H9pzNxVoCKBrRk8nACoWdrE8VtNmANPhUPqpyilVZVQnc+LwaC8XQDwJptIua3uL
 YdtNt9r64WtujyxXOzFnmhQOm7awXnGyqBAw4wv+eEpaX1g4hI+S6ztd8HEs42ayCbNZqqfTQ
 kViMcEYnkq2BnOwEBbgUQThiR8fWAS5xptpfw4iFzTqDXpUq+JFGY0kfjgaDMSUv+kxusz8Ii
 AMCGVOy/E6aUnFvavYMzfwxOnZmLWe/iCxAHIbK2uyRyMYyCiFRrnH4hHyZBQGYHkDN7UMeH5
 NM/ToSEBjm4//SYx8V2EBJuXk21JMLKNW8/G/8zI5MdLI=

On Tue, 2024-05-07 at 23:15 +0800, Chen Yu wrote:
> On 2024-04-05 at 12:28:04 +0200, Peter Zijlstra wrote:
> > Allow applications to directly set a suggested request/slice length us=
ing
> > sched_attr::sched_runtime.
> >
> > The implementation clamps the value to: 0.1[ms] <=3D slice <=3D 100[ms=
]
> > which is 1/10 the size of HZ=3D1000 and 10 times the size of HZ=3D100.
> >
> > Applications should strive to use their periodic runtime at a high
> > confidence interval (95%+) as the target slice. Using a smaller slice
> > will introduce undue preemptions, while using a larger value will
> > increase latency.
> >
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> >
>
> Is it possible to leverage this task slice to do better task wakeup plac=
ement?

Slice being unrelated to placement makes its use in a placement related
knob look wrong.  Even the smallest possible slice is orders of
magnitude larger than the cycle time of TCP_RR, making slice nearly
irrelevant to the issue being demonstrating via TCP_RR.  Even for that
huge socket box, it won't take long as cycle time increases toward that
smallest possible slice for the cost of needless wait to bury placement
decision costs.

> The idea is that, the smaller the slice the wakee has, the less idle CPU=
 it
> should scan. This can reduce wake latency and inhibit costly task migrat=
ion,
> especially on large systems.

Sure, this is an age old issue that's scaled up to size extra ugly in
that huge socket box.  Any solution needs to scale as well methinks, a
simple fixed yardstick won't work, as the costs being mitigated vary
wildly with platform size/shape.

	-Mike