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 28F6CC433FE for ; Fri, 4 Nov 2022 03:49:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230045AbiKDDt2 (ORCPT ); Thu, 3 Nov 2022 23:49:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229553AbiKDDtZ (ORCPT ); Thu, 3 Nov 2022 23:49:25 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C03313D70 for ; Thu, 3 Nov 2022 20:49:24 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id l2so3755471pld.13 for ; Thu, 03 Nov 2022 20:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=HZqxs8uWTrDmvN9Rm1lovMWAjs6urKSRKz66z+vX3Rw=; b=unUc3cqJWTXub7I+v9DHFWtR6nhT+zSg5+P2NO4GvTt2JYZq2JGa/lHVJXSZ14vVIp cAIWUs15SacaAxImNi2uo62sSJxki7IVlRZl8gzSCtMdRlyBp08gzJS8FXL2X9qus6bz 7E8Khh819KRAF13seVLz/2J5rg5P1z69k9LKDr8nHkdsBErZ3os0qhLV0WrRLLm3kYWa h872WlRhoj74XB/XHfF9bHHT8WE3l5LdbB278SuVustM+QOI6gGFBJNJ9KLMY8+q0PCb 5dyefLs3W/eyhwcd8s9DgdEuxKSXUTagodftAqzR+HhVRXMA7CC37lO9mo06kzDiJ0y4 PmCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HZqxs8uWTrDmvN9Rm1lovMWAjs6urKSRKz66z+vX3Rw=; b=GmOfkI3bCHhf62DevNItGQRaANFSTB4Pvzrz0UZIPAnIBOH5r9pqNtwK0qeKmRzePW fx8OiweTtipvibDRhlc+2JPcEE3e1SJsVCrWDijv4Yk1PsCkIu2WC/HpBHziAgGFBaqS MufdDOksAdTxA0LvzwmvheQ4kZh2JICZvr01/Mq523pUQIAtHX392i+Jg4eSBstW/Su0 vEad0Gk6Q+h1IlPoBSqXeeXK6zexNGdiXhH7wA6z1iygD5FGfAS57VbcULlhBCwjt7J2 7a5UVeMlzWYDpMkoMBezwtxQlV9uCKBQ/jnDqwUHZdoTwx37s7rbK40qTPI3SLrxVvf/ RplQ== X-Gm-Message-State: ACrzQf1W7XDk/rn7dpzYemRES0tlq63Sj2cwiBq3MXUdC7ShuWKu0mLD i3t7qmfLuWlx61Ix4hxgU2hqgQ== X-Google-Smtp-Source: AMsMyM5nR7nn6WMCxAdaydFQtOv8U+T5QPyc28QQadOK4/joHidWiwagE79RDgpn/HzANIjHFyPcTw== X-Received: by 2002:a17:903:11c3:b0:178:aec1:189c with SMTP id q3-20020a17090311c300b00178aec1189cmr32918108plh.136.1667533763484; Thu, 03 Nov 2022 20:49:23 -0700 (PDT) Received: from [10.85.115.102] ([139.177.225.228]) by smtp.gmail.com with ESMTPSA id z15-20020aa79e4f000000b0056bb99db338sm1541705pfq.175.2022.11.03.20.49.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 20:49:22 -0700 (PDT) Message-ID: Date: Fri, 4 Nov 2022 11:49:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [External] Re: [PATCH] sched/fair: favor non-idle group in tick preemption To: Josh Don , Chuyi Zhou Cc: peterz@infradead.org, juri.lelli@redhat.com, mingo@redhat.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, Abel Wu References: <20221027081630.34081-1-zhouchuyi@bytedance.com> <64d963b6-2d9c-3f93-d427-a1ff705fb65a@bytedance.com> <5af26ac9-3bdb-32d2-77a7-6cd8feca97aa@bytedance.com> <8142b5db-f543-57e6-0f68-f62274c0e379@bytedance.com> From: Hao Jia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/11/2 Josh Don wrote: >>> Some weirdness about this change though, is that if there is a >>> non-idle current entity, and the two next entities on the cfs_rq are >>> idle and non-idle respectively, we'll now take longer to preempt the >>> on-cpu non-idle entity, because the non-idle entity on the cfs_rq is >>> 'hidden' by the idle 'first' entity. Wakeup preemption is different >>> because we're always directly comparing the current entity with the >>> newly woken entity. >>> >> You are right, this can happen with high probability. >> This patch just compared the curr with the first entity in >> the tick, and it seems hard to consider all the other entity >> in cfs_rq. >> >> So, what specific negative effects this situation would cause? >> For example, the "hidden" non-idle entity's latency will be worse >> than before? > > As Abel points out in his email, it can push out the time it'll take > to switch to the other non-idle entity. The change might boost some > benchmarks numbers, but I don't think it is conclusive enough to say > it is a generically beneficial improvement that should be integrated. > > By the way, I'm curious if you modified any of the sched_idle_cpu() > and related load balancing around idle entities given that you've made > it so that idle entities can have arbitrary weight (since, as I > described in my prior email, this can otherwise cause issues there). If we want to make it easier for non-idle tasks to preempt idle tasks in tick, maybe we can consider lowering sysctl_sched_idle_min_granularity. Of course this may not ensure that non-idle tasks successfully preempt idle tasks every time, but it seems to be more beneficial for non-idle tasks. IMHO, even if it is allowed to increase the weight of non-idle, it seems that we can make it easier for non-idle tasks to preempt idle tasks by lowering sysctl_sched_idle_min_granularity. Thanks, Hao