From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F29F43B2A4; Mon, 1 Jun 2020 12:02:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 193B938A13; Mon, 1 Jun 2020 11:59:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5s-VljIpiNC0; Mon, 1 Jun 2020 11:59:44 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BA4838A11; Mon, 1 Jun 2020 11:59:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94026478; Mon, 1 Jun 2020 12:02:05 -0400 (EDT) From: Michael Richardson To: Dave Taht , bloat , cerowrt-devel In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 01 Jun 2020 12:02:05 -0400 Message-ID: <19625.1591027325@localhost> Subject: Re: [Cerowrt-devel] [Bloat] capacity awareness for the deadline scheduler X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 16:02:13 -0000 article points out: > The work of the deadline scheduler becomes more complicated in asymmetric > CPU configurations, like big.LITTLE or DynamIQ. Such systems include > different types of CPUs, with higher and lower performance. The same task > running on a higher-performance ("big") CPU will take less time than when > run on a lower-performance ("little") one. The deadline scheduler in > current kernels does not take that difference into account, with the result > that it can over-allocate the CPU time on lower-performance CPUs. Deadline > tasks could end up on a little CPU, scheduled in such a way that they are > unable to finish before their deadlines, while they would be able to do so > on a higher-performance CPU. On such systems, the admission-control > algorithm, which assumes that all CPUs perform at the level of the big > ones, could overcommit the system with deadline tasks, making the system > unusable. and I wonder if in some cases it is better to keep a "little" CPU (which presumably draws a lot less power) running continuously to deal with deadlines than it is to wake up the "big" CPU to do stuff. I understand that we learnt the opposite in the early days of Mobile CPUs: it was best to run the CPU as fast (and hot) as possible to finish early and suspend. Sometimes it was even power-wise to turn the fan on. But CPU-fast/sleep-long-time would lead to a high jitter on events that one might want to be more regular. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [