From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D784DC433EF for ; Mon, 23 May 2022 12:58:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235803AbiEWM6z (ORCPT ); Mon, 23 May 2022 08:58:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235726AbiEWM6y (ORCPT ); Mon, 23 May 2022 08:58:54 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80894527EC for ; Mon, 23 May 2022 05:58:53 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id i11so25222037ybq.9 for ; Mon, 23 May 2022 05:58:53 -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=glvNFTarGwjhG6/nAlpcwFLi6TN3OkPew5JbaTXKiDU=; b=TgxKoyWM+MA9O5OpBlq3Zf8r8lsU4Nnq0DR9oSD//Wqd8YmIPlLHLr5nTx32cK/stX 9nYfnG82HquzVq5UrSj1msNvJ3dXK5HUvWGNggY33SbYaNXwwWh+5KJ7dzV2RlByg0BY DUNJTX5gMNdA7VxOwiaBJQaD04uoFzfX20m4e0TMi34Y4WWBquYVLsKf7IRTWJAX6+yp VpNdk8wevHMfXVuDcyL0z3Cg5t8QJ3mQ/+vpA5XOYgAdoyu9g/M3W49o39w0rv1uMHTM 95GADoiV59C/2ucOV9cYNsqxFUOJcFQoj2q1zWFSXUXA7LYv7KxFSFScKLsy65ccya/C WoaQ== 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=glvNFTarGwjhG6/nAlpcwFLi6TN3OkPew5JbaTXKiDU=; b=cScqj5rNWMeZSmPp6aT5FCcV2etPIkRM8WgHjcS6k3i01QpAoP+A0SwmF5yfu2MW69 hAt44NAGd8k3QmrJcXPVt6eaBUt1eavIOaxbbL/b2Pdwdxs/jsCooi+2iTlfWzjJVAiw x/PrePG6NU3WhgkAcGa+G2dHPuKYXpG7hW8jhsJqq+PFwiBNyZ1vrqGK9qI+Bt2sCaJK ReRbUS2JOAy9peB4yOCIt0Evy91O8U57nQeAyQECrEF98OUbzBOtY6y3dOj5VlYYBEA5 bCmrtGQ9BbeMNvGVSAIvXlAr3XI51zO62JXIiQqFIOZHNYbtG8NHzG8rHWq6VTDh3J9g lpbw== X-Gm-Message-State: AOAM532SXLhUie4A4CX/bpMnWTTkJXABzueUcOuHszijoAwYzsWtLOBQ 64aUK1fHfvkxpdm7oM8ZxnJcsMCddfqvkrBoBZ1pZg== X-Google-Smtp-Source: ABdhPJx6QCEQg043DDUfDrm7m72OUym1Jm+HsRa6xV/JOLtYIOgfQ4H78rOKs6AUaqA+v3iuNLqS5TcRm3SokNbeCoQ= X-Received: by 2002:a25:23d2:0:b0:64e:a1e4:683c with SMTP id j201-20020a2523d2000000b0064ea1e4683cmr22059259ybj.211.1653310732706; Mon, 23 May 2022 05:58:52 -0700 (PDT) MIME-Version: 1.0 References: <20220512163534.2572-1-vincent.guittot@linaro.org> <20220512163534.2572-6-vincent.guittot@linaro.org> In-Reply-To: From: Vincent Guittot Date: Mon, 23 May 2022 14:58:41 +0200 Message-ID: Subject: Re: [PATCH v2 5/7] 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 , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel , parth@linux.ibm.com, Qais Yousef , "Hyser,Chris" , Valentin Schneider , patrick.bellasi@matbug.net, David.Laight@aculab.com, Paul Turner , pavel@ucw.cz, Tejun Heo , Quentin Perret , Tim Chen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 May 2022 at 22:07, Josh Don wrote: > > On Thu, May 19, 2022 at 6:57 AM Vincent Guittot > wrote: > > > > On Tue, 17 May 2022 at 02:54, Josh Don wrote: > > > > > > Hi Vincent, > > > > > > On Thu, May 12, 2022 at 9:36 AM Vincent Guittot > > > wrote: > > > > > > > > Take into account the nice latency priority of a thread when deciding to > > > > preempt the current running thread. We don't want to provide more CPU > > > > bandwidth to a thread but reorder the scheduling to run latency sensitive > > > > task first whenever possible. > > > > > > > > As long as a thread didn't use its bandwidth, it will be able to preempt > > > > the current thread. > > > > > > > > At the opposite, a thread with a low latency priority will preempt current > > > > thread at wakeup only to keep fair CPU bandwidth sharing. Otherwise it will > > > > wait for the tick to get its sched slice. > > > > > > Following up from the discussion on the prior series, I'm still not > > > sure why this approach is exclusive of extending the entity placement > > > code; I think both changes together would be useful. > > > > > > By only changing the wakeup preemption decision, you're only > > > guaranteeing that the latency-sensitive thing on cpu won't be > > > preempted until the next sched tick, which can occur at any time > > > offset from the wakeup, from 0ns to the length of one tick. If a > > > > In fact, you are ensured to run a minimum time of 3ms at least on >=8 > > cores system before tick can preempt you. I considered updating this > > part as well to increase the value for negative weight but didn't do > > it for now. I can have a look > > If the latency sensitive thing on cpu has already been running close > to or greater than that min granularity, that doesn't apply; can still > get preempted pretty quickly from the tick by the newly woken task. The 3ms is ensured from the task wakeup whatever the previous run and whatever can wakeup in the mean time but didn't preempt it at wakeup. As mentioned above, it is probably worth having this value scale with latency, especially for low latency task. > > A possible change would be to reduce the sleeper credit when the > waking entity has lower latency priority than the current entity (ie. > similar to the se_is_idle() check already being made in > place_entity()). > > > > latency-tolerant task wakes up with a lot of sleeper credit, it would > > > pretty quickly preempt a latency-sensitive task on-cpu, even if it > > > doesn't initially do so due to the above changes to wakeup preemption. > > > > > > Adjusting place_entity wouldn't impact cpu bandwidth in steady-state > > > competition between threads of different latency prio, it would only > > > impact slightly at wakeup, in a similar but more consistent manner to > > > the changes above to wakeup_preempt_entity (ie. a task that is not > > > latency sensitive might have to wait a few ticks to preempt a latency > > > sensitive task, even if it was recently sleeping for a while).