Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1547204ybj; Fri, 8 May 2020 04:01:46 -0700 (PDT) X-Google-Smtp-Source: APiQypLlyqwSjBElllJJiory8g4vL71rVGoKbIcpgligm/a+z5y6daM5q+5b/OfuceUFFoZSGFkp X-Received: by 2002:a05:6402:3047:: with SMTP id bu7mr1602903edb.303.1588935706092; Fri, 08 May 2020 04:01:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588935706; cv=none; d=google.com; s=arc-20160816; b=KuYVr8EC8MLW7G1SSiMvkSTkM/85S2DC5NVtyyoXHuKckz4mfoBEdMpsS7oVbxA+jh +49weUDmsWxZzn0jBG3bf69+QJHYfPe8ofzcswxzLQLYhDqfExBQkFzgJzjg8JKR3kyz xLdfpFNgIJVmAWLzVgt2u1akY82LbiK8/51NIHUFhEXRhtK9yPA9/Wz3RLBBDEMWGVIz Swao4KonvESO4DqZCVNabHtQsEDaXu4mn3grBKZ5ZOfGByOasn1pdrnnRvOzctHRgTYk rib/DnJerkPdv7NlFh3lUZ0Vyl+DqJeF1c/Q9JSxkWmBArpedJlJLjOePYngDgfAhsp9 nw3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=rNz7muc9xKqzaJOd2r+kypdEfBgVQbCAV+X2l7maFGE=; b=CcHTn1kCxVyZ53JMvoHipKvPXTh4I6HW3SpavxBb5ityjCX1x0XhW6A8x70ugmrkYc CiGae5TYJ97XP6nC0CmTolrVD44aigfKIeRH6Y2Hj6xwR78eDCfmffyrYk3VIYdvyffZ lc3q1OE7T8Y3gUVQDQ9l9nVZulwEtVKeyxV5+8BBosfeGjlzXanaIRU8o5q3fWzmZIw/ a1QL6lMGaxiaaYYj8vdx48lsMhZATxRHVpKYj8QebEfhTvUxsuzuSptpvbwDXhkIcjck pJg5+Fudp3EXdusS6tqTCeMjh+4gWnZbNICYoFq/J2H1z7hVNo6X3hmeuhg+Vs53ef8a JwdA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m10si693147edr.459.2020.05.08.04.01.14; Fri, 08 May 2020 04:01:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726815AbgEHK6m (ORCPT + 99 others); Fri, 8 May 2020 06:58:42 -0400 Received: from foss.arm.com ([217.140.110.172]:46518 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726091AbgEHK6l (ORCPT ); Fri, 8 May 2020 06:58:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6C3A30E; Fri, 8 May 2020 03:58:40 -0700 (PDT) Received: from [192.168.0.7] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D040A3F71F; Fri, 8 May 2020 03:58:37 -0700 (PDT) Subject: Re: [RFC PATCH v3 2/3] docs: scheduler: Add scheduler overview documentation To: Valentin Schneider , John Mathew Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, corbet@lwn.net, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, tsbogend@alpha.franken.de, lukas.bulwahn@gmail.com, x86@kernel.org, linux-mips@vger.kernel.org, tglx@linutronix.de, mostafa.chamanara@basemark.com, rdunlap@infradead.org, Oleg Tsymbal References: <20200507180553.9993-1-john.mathew@unikie.com> <20200507180553.9993-3-john.mathew@unikie.com> From: Dietmar Eggemann Message-ID: Date: Fri, 8 May 2020 12:58:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/05/2020 23:15, Valentin Schneider wrote: > > On 07/05/20 19:05, John Mathew wrote: [...] > It would also be an opportunity to have one place to (at least briefly) > describe what the different sched classes do wrt capacity asymmetry - CFS > does one thing, RT now does one thing (see Qais' work), and DL will > hopefully soon follow (see Dietmar's work). > > I'd be happy to contribute (some of) that, if it can be deemed useful (I > personally think it might). I like the idea. Essentially all the code which is guarded by the 'if (static_branch_unlikely(&sched_asym_cpucapacity)' condition or which sets it during bring-up. * 'Cpu capacity < SCHED_LOAD_SCALE for non-big' CPUs setting during bringup (necessary dt binding, CPUfreq influence) * CFS capacity awareness: * wakeup - select_idle_capacity() (replaced wake_cap() & slow path to cover DynamIQ and classical big.LITTLE) * load_balance - misfit handling * RT & DL capacity awareness * ... & the relation to EAS (Documentation/scheduler/sched-energy.rst) This is what we referred to (at least internally) as CAS (Capacity-Aware Scheduling).