Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3465651pxb; Mon, 4 Apr 2022 17:52:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+XE308nx1D9St8GZEaiuxqeXS2hkohwIjSTEG/xRTPYnQD0iBFWjtnE1Uj5y3xkUigBI1 X-Received: by 2002:a17:90a:31cf:b0:1c9:f9b8:68c7 with SMTP id j15-20020a17090a31cf00b001c9f9b868c7mr1155283pjf.34.1649119928803; Mon, 04 Apr 2022 17:52:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649119928; cv=none; d=google.com; s=arc-20160816; b=Dzj5084nDeLlmFwzS5veP0DzMSN1oBt25KaYshJKhTQYGqmt2rSTG5X3mXrn9URQqe c8Dc85ODUIvZ1INsavdwWSDkzwZpI1Jiqqj4sN9QpZECL2rG2JUtCox4Bu5k5b9fm9jS 3q0bnFe9G0CfA2fdHoxczzP9ARuao1MB0KqDT+atmdq5O9lZHf25A2aNufbo5PBHtgBr zQpGH8Klyl4I70qvEEZvP/0O3aMqJCtJ1qrbPQHLE2jtQUm3qTXQJtxKKbhT85I5hYM9 b50aeOago88DpuqAq57NnKjKpBneRobpnm2I6/Wgqys5Ntm4+X3EQ67Statnw9BD9Dr9 btmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=aj9XTAr/1wAKq1WVY1B1OGIPL9lJ/xIj7GaRUxg+TfU=; b=ONFeJ6JMF2/R7/e2Pafsj+nxM3hEbNx4nRJiII1kRHMuIRDVbhOKhkRmJXfxydL4Lx wMAlzJTAuZtIIt5NArk6srbDzFhmKfGRzSGEHmZmxoU+7nXgHe1efUy71hEdhFOCChP4 Hdhg7tqTKI7iZfn77fsNS76kjt3zlRN1dyPMOEYF6//mAd8LR4SBOj94DdEwTKTHg8SG +OK02Cwlux8I44mk9KbJjn8okYpqg9grNptK871K2DGtw3WWVHB/Ah2PISNZnFVUIIci lorzrIjloF3EGDOswoupaF5wVORpBvo9eXOT3EFZ0VxhknT9orT54Qm5NS1KQVz00rgw eA8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uqzITrCu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id cp12-20020a056a00348c00b004fa9292ffb9si10806796pfb.354.2022.04.04.17.52.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 17:52:08 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uqzITrCu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 63709F2111; Mon, 4 Apr 2022 17:00:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346826AbiDBIsq (ORCPT + 99 others); Sat, 2 Apr 2022 04:48:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244967AbiDBIsn (ORCPT ); Sat, 2 Apr 2022 04:48:43 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFC0F1AAA4B for ; Sat, 2 Apr 2022 01:46:50 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id 17so6731720lji.1 for ; Sat, 02 Apr 2022 01:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aj9XTAr/1wAKq1WVY1B1OGIPL9lJ/xIj7GaRUxg+TfU=; b=uqzITrCuEDxkVhSaiQ69/mJhXL9nTyP0pEssq+Ygi9Ic3nj/wAmXNBMtMbtIqIUFQy l1pFEKZrlmy8hiXmYcdX18ODqT7VG7JPnvg0iK84enJjXvZFfLSjwXuXcjmxQvhprKsy e6QnjLim42Pgp7Kn024P6PPTT/Qp/eeZPxBiCo1GnZsLEkX+XyWj8urhj41q0j9K/+zy Sfy4kf4C8GbNGEH5Ee++3Ybvg95WG8hix8SgsL415C7vZQEyBuAF9RyR0KGc4bNr1ldR KNXLoJjgx1bTj3SruwRLUY9JZW8q8neNiHEu8YFXjN1xCKMY1If0Gvog3O4WWPz2Bx/v jWtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aj9XTAr/1wAKq1WVY1B1OGIPL9lJ/xIj7GaRUxg+TfU=; b=6R5xKociWmtC5qRgMGvCyj3yvbk1ym9rY97EosoZ59+4Ry31RDL4ZUUKWcEnIt6yYb 1hOC/R7ZLXUt5yfo5c0tCV7a+K6vAUrpYiZKTaS3VbNQwZNQljJKpUQid3msR7Jb4CYP 66s1pLl0gceD1CktpGn/xDb/JEHo6LAZCVJ9dcg7EJnDH2wqulvZExk88/H8G0KD3fFJ zF0NSW2D+XJDzBBnSjp0W1UsHM59on/MfuFVxvkoaN2m4R8azakxQ8nPiU/HVLjx3pMg eshG5r8Ho0LRhhgeQhCtfeMsVJAObEjY+MdVLR8cglqb0OpFfMiR43kJSwPkMRqoKHtK T33A== X-Gm-Message-State: AOAM533o9cKRGxaf2hT3Bz3ZJKMbPpzFm/RJ2a2a2ssGvWxkow1YCpNX b1JEgywmVi6fisgTv5xINBL0ZWy4wMmDP8qeU7FslA== X-Received: by 2002:a2e:7d05:0:b0:247:ed41:690d with SMTP id y5-20020a2e7d05000000b00247ed41690dmr15812746ljc.92.1648889209127; Sat, 02 Apr 2022 01:46:49 -0700 (PDT) MIME-Version: 1.0 References: <20220311161406.23497-1-vincent.guittot@linaro.org> <7a7e1e21-df3d-4623-d9cd-51f5272919d5@arm.com> <20220401121525.flngciwjtkn3mwlv@airbuntu> In-Reply-To: <20220401121525.flngciwjtkn3mwlv@airbuntu> From: Vincent Guittot Date: Sat, 2 Apr 2022 10:46:37 +0200 Message-ID: Subject: Re: [PATCH 0/6] Add latency_nice priority To: Qais Yousef Cc: Dietmar Eggemann , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org, parth@linux.ibm.com, chris.hyser@oracle.com, pkondeti@codeaurora.org, Valentin.Schneider@arm.com, patrick.bellasi@matbug.net, David.Laight@aculab.com, pjt@google.com, pavel@ucw.cz, tj@kernel.org, qperret@google.com, tim.c.chen@linux.intel.com, Wei Wang Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 1 Apr 2022 at 14:15, Qais Yousef wrote: > > +CC Wei > > On 03/28/22 14:56, Vincent Guittot wrote: > > Hi Dietmar, > > > > > > On Mon, 28 Mar 2022 at 11:24, Dietmar Eggemann wrote: > > > > > > On 11/03/2022 17:14, Vincent Guittot wrote: > > > > This patchset restarts the work about adding a latency nice priority to > > > > describe the latency tolerance of cfs tasks. > > > > > > > > The patches [1-4] have been done by Parth: > > > > https://lore.kernel.org/lkml/20200228090755.22829-1-parth@linux.ibm.com/ > > > > > > > > I have just rebased and moved the set of latency priority outside the > > > > priority update. I have removed the reviewed tag because the patches > > > > are 2 years old. > > > > > > > > The patches [5-6] use latency nice priority to decide if a cfs task can > > > > preempt the current running task. Patch 5 gives some tests results with > > > > cyclictests and hackbench to highlight the benefit of latency nice > > > > priority for short interactive task or long intensive tasks. > > > > > > The Android specific `latency_nice` (in Android `latency_sensitive` > > > [latency_nice < 0]) use case `Skip energy aware task placement` favors > > > an idle CPU over the EAS search path for a `latency_sensitive` task. > > > > > > https://lkml.kernel.org/r/2aa4b838-c298-ec7d-08f3-caa50cc87dc2@arm.com > > > > > > This is Android proprietary code similar to what we have in > > > find_idlest_group_cpu() in mainline. > > > We talked to the Android folks last week and IMHO they are not convinced > > > that they can switch this to the proposed `latency_nice->tweak > > > preemption` use case. > > > > Thanks for discussing this with Android folks. It's not always easy to > > change the behavior of a product and I would be interested to discuss > > this with them. Sometimes you need a PoC to get convinced > > I think it's good to clarify for me at least here whether you intend this as > a replacement for disable EAS and revert to CAS or you see this as an > additional thing? As I understood from the discussion we had on the cover > letter, this is an additional improvement and not intended to replace any of > the previous use cases we brought up before. This is not a replacement but an additional way to improve latency. The only thing that could happen is that this feature provides enhancement that makes the policy of disabling EAS and revert to CAS becoming less or no more interesting. > > Wei/Quentin, any thoughts on this? > > Thanks > > -- > Qais Yousef