From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E2D9C76196 for ; Sun, 2 Apr 2023 06:28:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 302426B0071; Sun, 2 Apr 2023 02:28:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28B8C900002; Sun, 2 Apr 2023 02:28:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12CA06B0075; Sun, 2 Apr 2023 02:28:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F2DCC6B0071 for ; Sun, 2 Apr 2023 02:28:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 73BE0C0666 for ; Sun, 2 Apr 2023 06:28:51 +0000 (UTC) X-FDA: 80635472862.14.776B29E Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) by imf15.hostedemail.com (Postfix) with ESMTP id 9792FA0007 for ; Sun, 2 Apr 2023 06:28:46 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680416929; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s0ubnqyt2QGbvo3Omw+X3OHyQk/IPoNLeV1emHknRqI=; b=BCTj4t0RPzVJVKEXu58xEI9qc9FdAAhmw6VxzZ7keeP7t+gEnj5EsEZk72TiYtBHEZe8Vc CYPJSh9E/0L3RCgARTWxgw4cwvu05zKpVbG29opvAHJ+QG3dU6A6oI9pfW5QcStyJAoPEI 4/WuahAYdutkCd3kboPYu2jMXO1Fogs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680416929; a=rsa-sha256; cv=none; b=qyTjYK505C0crd2VQpIUyR+Nm/MiLleKME4XhHFqwd+PTaN/LXQW1OGx4uVZ/WsrgswIdx CJ/C0RvnO9etpuZNNHF0bGasQyFGzQe+NNPNU1aFhhMUe6zRDywqBhNItnYn21MmqJ8Z+V V7pEFxvTXcD8gmwx0DrCs871fKjttzo= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.27) with ESMTP id 642920820000A7A7; Sun, 2 Apr 2023 14:28:20 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 10955649283613 From: Hillf Danton To: Mike Galbraith Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Peter Zijlstra , rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, corbet@lwn.net, qyousef@layalina.io, joshdon@google.com, timj@gnu.org, kprateek.nayak@amd.com, yu.c.chen@intel.com, youssefesmat@chromium.org, linux-mm@kvack.org, joel@joelfernandes.org Subject: Re: [PATCH 14/17] sched/eevdf: Better handle mixed slice length Date: Sun, 2 Apr 2023 14:28:32 +0800 Message-Id: <20230402062832.407-1-hdanton@sina.com> In-Reply-To: References: <20230328092622.062917921@infradead.org> <20230328110354.562078801@infradead.org> <20230401232355.336-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9792FA0007 X-Rspam-User: X-Stat-Signature: rbym65m9nnpjb9hqz9u71ixr59meza9k X-HE-Tag: 1680416926-237339 X-HE-Meta: U2FsdGVkX19UwCB4w7wD5gkuFErRi0cwszIDz/vxSs6j4ogxyHTjbY1gDEbB/bk0yJg2n5i6hzEBrhNTTapotr71FgQWWic6UbeZm5nmChZ6CmAPnp3TFowdZmIrTqfcNLRYogi47tKWJu5nx6eUyISdRwCv9ihNb5mK0e/ACCf51nQ1H+UVmC783KhcoDGGweAz4u2SuGglw1+/VeMewusiFAzPmREslWHpocUL2H+UoUyR9qi/FDFtuIgc8H5vtF1TE215nWGCgYYr6ZR868ZQUWqexaUu3rIq6+8jYJLFMetnm4GZpyTWzip+MU6VGmxwY1rhsJ/U/CQgc1CMeKaB6Vnvg5z4qt6X03Rr75UtcirSbxqHUhofCph7SHqQNCdfThyTgPy0bpO+v4qNYmZPc0GkEY6+v3fLaQA6AHq0FZWh9lySGIpLI0QdTexgTAlUaef9z+BDtS/HmHlbJbjiZfLLmsuVVCcDuDVHRwG2rcMwO2FjGXxEYqVujF3TbUidXxtPVVyE3e20nOqhcj/gSppRkeAEeEuk0g3BfJsLumO07ZMQB5GPQC5x9I4hz6aP62yxiKy+zfzZP1leI9J7n5J1arz0XCU3exlnL+Gyc0Ulxi8wsRqjNNOjS9eNYJpjSDFCy9EXVPi4Qx2ggvwh423FAmU9Y4X1iZGSzkbN3gZOsd8Kebz7xudSMi/2Z3Fslt9Mgg7oW9KjnsWMooCXwj7JfuzJp2ZknJ76/hQYmyxZwAYLjsqzx99/OfPL4ua3sN3I0l20fzbdVGr7QGzACAQvWzgsaGudaE1JPud4Hq0wllIEi0X7BQSUMdhK6268b0Gx+vIvvDHh7S2xhPM/t65dkx0wfjHsgElPS+BOwpp1vurCAfqUlmxATW+Y/3QGTFjxtJx6CzBK/DGf7H5GM+8YpplzqbdRy+L0KYrV1vEDefTbmRgesDmAnXfrYgb4/T+N+VNs3QCCOVV yEwXUpTP F0sYvjP/9YkIouyij4KwHaiI+ij3NtS1H2on/4OhwqgVcXj9+D/W/yb1aJ0ZVlTiDeBLyPFytncZAyzefvZZPoSXTJNslPTYibVmVYTHnzlExzaNg4OI0xLk9f0sxAzMwhrJy6s08DP/+X3FCbCBXWAlBRgv0LHZ/2g68 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 02 Apr 2023 04:40:20 +0200 Mike Galbraith > On Sun, 2023-04-02 at 07:23 +0800, Hillf Danton wrote: > > On 31 Mar 2023 17:26:51 +0200 Vincent Guittot > > > > > > I wanted to stress this situation with a simple use case but it seems > > > that even without changing the slice, there is a fairness problem: > > > > > > Task A always run > > > Task B loops on : running 1ms then sleeping 1ms > > > default nice and latency nice prio bot both > > > each task should get around 50% of the time. > > > > > > The fairness is ok with tip/sched/core > > > but with eevdf, Task B only gets around 30% > > > > Convincing evidence for glitch in wakeup preempt. > > If you turn on PLACE_BONUS, it'll mimic FAIR_SLEEPERS.. but if you then > do some testing, you'll probably turn it right back off. > > The 50/50 split in current code isn't really any more fair, as soon as > you leave the tiny bubble of fairness, it's not the least bit fair. > Nor is that tiny bubble all rainbows and unicorns, it brought with it > benchmark wins and losses, like everything that changes more than > comments, its price being service latency variance. > > The short term split doesn't really mean all that much, some things > will like the current fair-bubble better, some eevdf virtual deadline > math and its less spiky service. We'll see. > > I'm kinda hoping eevdf works out, FAIR_SLEEPERS is quite annoying to > squabble with. Yeah no matter whatever role FAIR_SLEEPERS could play next week, this paves a brick for Vlastimil Babka to take it over leaving Peter happy to sit back with netflix on.