From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C03A23B2A4; Mon, 1 Jun 2020 16:31:17 -0400 (EDT) Received: by mail-io1-xd2d.google.com with SMTP id k18so8446051ion.0; Mon, 01 Jun 2020 13:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kmio0LjtbmxMqzpRiBec/t6+p0w5gFqxQa+r8rIP1tY=; b=g7yTV2+vsC41/bC1Y2OWlg1st0iOVOlZREvCg0OjPdp9RPD7jbchkFNkMflx9wT6Wi 1z6op+UudZ3JCPq5LhPBJUljEhZOIUuGGMujXxoiLjritxRq4auSxUPyiVo43Uyzm8e8 8wD674WnlcnD3o+kXb8PauSSB+3hbZ0xqhwc/lfUsa4qLeFatGyDNSUsAWLMiZ7x7vrS py6LDQEYP3iYyxVV5TtYx2qiFN4a77UBGXiEfCsY7K6LQpRIqPdazijs6MPcQTMfrWLG gv/3jNcCdf46wIFAEJ+gPqmPj/J75dCex+eg9MUWT/PKpouDiSVAPNczKh/m8lC5GPJ2 ra/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kmio0LjtbmxMqzpRiBec/t6+p0w5gFqxQa+r8rIP1tY=; b=TstW7Tu8QCZqDJ8VD7EUr+uBqAzN6/g/IbadWVPrD8zFLNkpini/ZiuPbGyfEpr612 8qa/gqbWikAYZFNJ/ov1XF7SbUGjH/3QKGaZp5NFYlzOA1xmDdXfDgy32I95jC0qiO2g jMgHOq6S3AnoJ68XTZmxtTDJuqfYItLkr0T0k7B/vUnM2yEDGyFmUwsPe6OHsaDfXMLe NworkJpl4TolHG20wf6IP0DqToftPeelF8Sp9sMcW0hldqIgH1wyjEAwzcF0rN4ePQFW DchJCgavaaWHE5deDdiOMP1ezZ6Tq5A4oO+dA/1Y0JM1b+mbxAMjDiwBhu2EwyYJpw5G S9kg== X-Gm-Message-State: AOAM532KQd2hAYknRb6u2OwCPP3lncV1ebqRa1nwj4WRbbPjPlPQ0uIs KPpug2urfA59vwLmbT2RRyWrP76yTnlG3r/fVr2m6g== X-Google-Smtp-Source: ABdhPJzLWvyOQGgdIQvdDKbDgds9G2xj8a5pDlsYbXeweh8pl/Hg2wrW435AfMZCBDNt4lEDbiNHWBe4xAMdoRk8MRI= X-Received: by 2002:a5e:dc03:: with SMTP id b3mr21013525iok.27.1591043477225; Mon, 01 Jun 2020 13:31:17 -0700 (PDT) MIME-Version: 1.0 References: <19625.1591027325@localhost> In-Reply-To: <19625.1591027325@localhost> From: Dave Taht Date: Mon, 1 Jun 2020 13:31:05 -0700 Message-ID: To: Michael Richardson Cc: bloat , cerowrt-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 20:31:17 -0000 If you want consistent low latency dropping in and out of sleep state does not help. But putting a deadline oriented task - like networking - on a smaller processor, seems like it might work. On Mon, Jun 1, 2020 at 9:02 AM Michael Richardson wrote: > > article points out: > > > The work of the deadline scheduler becomes more complicated in asymmetr= ic > > CPU configurations, like big.LITTLE or DynamIQ. Such systems include > > different types of CPUs, with higher and lower performance. The same ta= sk > > running on a higher-performance ("big") CPU will take less time than wh= en > > run on a lower-performance ("little") one. The deadline scheduler in > > current kernels does not take that difference into account, with the re= sult > > that it can over-allocate the CPU time on lower-performance CPUs. Deadl= ine > > tasks could end up on a little CPU, scheduled in such a way that they a= re > > 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 syste= m > > 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 o= ne > might want to be more regular. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | IoT architec= t [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729