Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp33480pxp; Tue, 15 Mar 2022 22:56:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRqB2w82X9D76FjTMCFLwZF+Posy+pSe0Kf5QddZTtqic3juDoAmuW+V7uKVpsIpyUApK1 X-Received: by 2002:a17:90b:1b0a:b0:1c5:f0d9:f8ae with SMTP id nu10-20020a17090b1b0a00b001c5f0d9f8aemr8527630pjb.221.1647410210018; Tue, 15 Mar 2022 22:56:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647410210; cv=none; d=google.com; s=arc-20160816; b=v6s2JwLy+NrgKGury8dJhH31ZmB5lch8jzyvtjJWWumMFEXDXcwjYyG7z6zXAmKPyP HC3H2IPzGMZkFO9RjRvIHCpVa025d8JStux2Xdt3Mj+kMHWaLjaHTq7jckQIOFYr/B2T uvlhPe5vA+wa8kuZcta31mlGco53dxqLdeHIRfJC9NqXbfKlyXWW2//sng/+Klk3RECV 1j5w9QD+oDlBDmAtjePkWmajiA+I84+RkFF1fKdeWt6rp6tRZzBCfm9soakVr5eQIhXy MMVauyPmxpIXVt0J2Z2DeVxXea1A3+p51w0krAvdP6jh6ULPeHuUqWJvtv9MYlr9jSyr hmXw== 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=wbMw4cdXweFkAK6j6U5W3V1cAn1OdMOoliVOt8SyHS0=; b=WDDIR+ADtPiZx9VepX7HDwuQgB/GDuA9TkNAKOCvRNMzOsDQpNMEIhD5Tq671G2gSo 3YIoSLQpZK9aX5zNwCZ4pYdJF7tiXJmpQDCwjyMWs3+Qr5h4jgOwcveLxxwkwTRdxSK/ k0iyP+9HRplLho8Kz0uweU47IO71Q+3h/yorPzBfP7LVgYdPH9xlQ+HWOLLLCog66xwF 95wOE5zs9Z+zjFrh5BRdgOkEnDY2atoFkRsHtuydLyWR5BtAwcFugkwRiTweu7yXuuh/ 9Wq4s9vvXjym8xWCLvFTiGmZyvQA28UZ07L8O4fEH8nAjgIwbRBRWE1PGXxxTt1TLhEe 7I4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JV5Ehtv1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y16-20020a056a00191000b004fa20691975si1266182pfi.49.2022.03.15.22.56.36; Tue, 15 Mar 2022 22:56:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JV5Ehtv1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348835AbiCON4S (ORCPT + 99 others); Tue, 15 Mar 2022 09:56:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234858AbiCON4Q (ORCPT ); Tue, 15 Mar 2022 09:56:16 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B62BF53E0A for ; Tue, 15 Mar 2022 06:55:04 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id w27so33172991lfa.5 for ; Tue, 15 Mar 2022 06:55:04 -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=wbMw4cdXweFkAK6j6U5W3V1cAn1OdMOoliVOt8SyHS0=; b=JV5Ehtv1rh9HFbOVWcAFnBeIPRNwqANJ+lB/BoC0ugx9NEWIR4C7uMn2MR547JYTuV IufzHYUIRj1drdLHyDPPa4RCno6aPt8/R2PK2WsW5v8DiUz1hFXJrKwZ2BGfF8hE6VOK MnOL+/sCmSQSjWQQlZdqMwMphyh0d3731ERhONIpFuEcUxXRxS1RKlB1uEZGSrdjSKb9 1c6Ji3VJJcJnNaxXA1raUTKG5v0VnFylwGG7TC8OmZe/naqUr4Gn/hvlPL3giYt6swo2 BsmC6dUDWQr08KkyaN/IqdYKbh5ZiPSo6J7N7WOB6aKleSuCKOKVh6shvYp7odcC7idA WwhQ== 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=wbMw4cdXweFkAK6j6U5W3V1cAn1OdMOoliVOt8SyHS0=; b=pfXFr6OHIr1URDjQv0Fed8KFkw9dC3yiE6QSZ5LKLEbywtRtbM++weSd7/FgfN5SxM zxdA4VW0gZLL+Pc9oxWqhplLeC23EEi1eYw0S++Uv+Q077HtS5GtCwIkOFhZZ0BnZjRO clW9cd9yOqrjFWfJEqfsEip2xt+WhM/9OetHqG/yRDYJdoq9Sa78vPxXejKGqCmMX70m 8mLbh7oPjo5PI+BGn5928831Tbx6x7ozZGS9GI1hShUM53UKBfqeKK99iVlob5xFRoQG b1/xZmM0ix2rgCV7T7xGVIJDmtY0gJ2ILTIlTLRFBtcl+qh5BXbP3knyr6bXnqbu5RpS rKNw== X-Gm-Message-State: AOAM533Ko83MFa7ftnkwHm0ndhBpw7dgEqtDGiBF5ytFk2OMJT8rrTi4 MCQ8mnPS5fuRGc4sQiGe9AIV3y/BUffcoAIWR5UKrA== X-Received: by 2002:ac2:554a:0:b0:448:2a09:66eb with SMTP id l10-20020ac2554a000000b004482a0966ebmr17025105lfk.645.1647352502958; Tue, 15 Mar 2022 06:55:02 -0700 (PDT) MIME-Version: 1.0 References: <20220311161406.23497-1-vincent.guittot@linaro.org> <20220311161406.23497-6-vincent.guittot@linaro.org> In-Reply-To: From: Vincent Guittot Date: Tue, 15 Mar 2022 14:54:51 +0100 Message-ID: Subject: Re: [RFC 5/6] sched/fair: Take into account latency nice at wakeup To: Josh Don Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , linux-kernel , parth@linux.ibm.com, Qais Yousef , "Hyser,Chris" , Pavan Kondeti , Valentin Schneider , patrick.bellasi@matbug.net, David.Laight@aculab.com, Paul Turner , pavel@ucw.cz, Tejun Heo , Dhaval Giani , qperret@google.com, Tim Chen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Tue, 15 Mar 2022 at 01:53, Josh Don wrote: > > Hi Vincent, > > On Fri, Mar 11, 2022 at 8:21 AM Vincent Guittot > wrote: > > > [snip] > > + > > +static void check_preempt_from_idle(struct cfs_rq *cfs, struct sched_entity *se) > > +{ > > + struct sched_entity *next; > > + > > + if (se->latency_weight <= 0) > > + return; > > + > > + if (cfs->nr_running <= 1) > > + return; > > I don't quite understand this nr_running check. just to return early if there is no other task running on the cfs > > > + /* > > + * When waking from idle, we don't need to check to preempt at wakeup > > + * the idle thread and don't set next buddy as a candidate for being > > + * picked in priority. > > + * In case of simultaneous wakeup from idle, the latency sensitive tasks > > + * lost opportunity to preempt non sensitive tasks which woke up > > + * simultaneously. > > + */ > > + > > + if (cfs->next) > > + next = cfs->next; > > + else > > + next = __pick_first_entity(cfs); > > + > > + if (next && wakeup_preempt_entity(next, se) == 1) > > + set_next_buddy(se); > > +} > > + > > What's the motivation to do this with the next buddy vs using wakeup > entity placement to achieve a similar result? The latter would also I don't want to modify vruntime because of latency prio because it would mean impacting the cpu bandwidth of the task which is managed with nice priority. latency nice is only about preempting current running task > more generically work when we aren't transitioning from idle. It also > doesn't suffer from some slight weirdness here in the interaction with > core scheduling, where rq->curr can be idle despite the presence of > runnable tasks if the cpu is forced idle. TBH, I haven't looked in details the core scheduling part which adds another level of complexity when selecting which task should run on the core