Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp50857pxb; Tue, 24 Aug 2021 19:49:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzb00cs4r2KblIIz1tQ36EEodYMthKi9IW5TSXQqHuOjD30ZNFkPJITEpsXOjNF8KNG4MZX X-Received: by 2002:a02:84c2:: with SMTP id f60mr36994268jai.133.1629859749088; Tue, 24 Aug 2021 19:49:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629859749; cv=none; d=google.com; s=arc-20160816; b=qZObUpuyqCl95HWDz5STjCyshN8zdL/GqpiAwjAy8gXofNKC8AVMdZ0S7vh5BJaD7m cNsFd6S3sGqFQmEYVl1fZ6DV2+sPxqHOJXQjkFw8I81oyxgZNEIao17kAZWgDjNUgbBa xOuf9YT+WezMoBrSp296qbJ+9E54Oe+yltkM5apOnohwjYQh2y9z5fAXoekioGXo8t8t K7kLCJHsgRctdh7ATMJNJhKxvjwrVgnpkLqdXnoi5ca/yeRadi16AxoYcdX+rckH4PcT gFBDSv2Ig1aGMOKVIpRm+p9pvWtZmEv8SaTaxjjLwTVhPEH00iqzuY2EInSUXEh9rRgW jCRw== 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=SxC1+YhfNm3L+87e5dL6LciurChnpO9y5/7AeLBJ6Yg=; b=olovtpPeYmwRMbAGNGxaSa/hXnXtdhrlinKz/iL/9vxzeTbLu8BQJvszwc7KhOt+u1 RknmDzXdSU1oj3enBFlgMNe+TyBzR5yU5h95fJpXKJHUUiHWLvAQCLWmpNCuhDSMg/cv IPP0VSynqJmQpwGkdaniDGBj7Q5ZHgYyjcR7msqkvqIHp4IRjmjY4A3SyWqoG6R7r8ls LDDQdoPQGaQccESdWkJ9hHasov8Lt5sNN0Z9bNGw/W+Gxo+DdblEKnC6WQSmMMYH/6F3 0k65A4iK/u1U7wS1GGKGnmAhPkLhxK6SWd23teWvV6iHcpkDId30fv6K5Qe0s47sEaT2 aH6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SHMH4CZk; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n3si17209133ilo.133.2021.08.24.19.48.57; Tue, 24 Aug 2021 19:49:09 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SHMH4CZk; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237707AbhHYCox (ORCPT + 99 others); Tue, 24 Aug 2021 22:44:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237741AbhHYCow (ORCPT ); Tue, 24 Aug 2021 22:44:52 -0400 Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FD1DC061757 for ; Tue, 24 Aug 2021 19:44:07 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id g66-20020a9d12c8000000b0051aeba607f1so43195040otg.11 for ; Tue, 24 Aug 2021 19:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SxC1+YhfNm3L+87e5dL6LciurChnpO9y5/7AeLBJ6Yg=; b=SHMH4CZkEaQGscoY3Q5gncthJNAp99J/t2p992voK8qZ7mrp4aNHVhXV3rFxFGuPOp XDtXilswms9fF5NyT1ZDTdniAeBC4PUOY4UvZb3JpTZ3Y/kUf3I4nB39ptJUwJIr9jCF Rn1m3ZJfwMGvk1ukIyTsceHCXn6jLTLJLpBhsFXQJs1HHLyrLdgEO17KL/MDHvO+kwgd Yk2B+/90B4kk05mmLKRF72pOJ1r+ksXgUGOdxK/Ow+JJFDiGWGGTmzDv/BsgzK2xL6oZ Jw3IzkfA6UkAuf3MfVrFAvH3F/Ap/XNLVkMOxDmDGdFujME4rUPgxSz60fvgpLfDY4Ih RcRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SxC1+YhfNm3L+87e5dL6LciurChnpO9y5/7AeLBJ6Yg=; b=dnkLzTZm9GDKtuimvT3p83vlQt3OYxxYd9GmV83Ke/XYEzdhjWEBnjoasB4fHcdXHw 2XYtvl6/ItFj0c/Sh4pkJlqhCKAmxbMl02p0d5xXbEOnwdSytdeeUvIarfHX8jZ3VoV3 vCZ6Yk+IO4D+rRBMfH7zYJOg7XAASDkv/krnhy2fq15148+E6XqOX3T9V9CzYPt2IJyI U8aRSoB4WyDQDob7ylEYhxESCxXSmXgSlBkLIK5/h0YD4wP9XvCN+vMMsDw7ZvePSaQi ArzKWBg8xZzSLdV8AgQtMXj/stmPOmv26bih1aNO/KyKD8JA/OgON12jhSDVf5Nqee8z GZmQ== X-Gm-Message-State: AOAM5338DY01xpu1XgymKyNzOk2HGelwgnLQ/haSCZcJiBq90cYgN11q iRDYgn7OFBnRsbGXQ+m9F3/AsZ0xUxCgvZFxcjY= X-Received: by 2002:a05:6830:1f55:: with SMTP id u21mr34984801oth.4.1629859447082; Tue, 24 Aug 2021 19:44:07 -0700 (PDT) MIME-Version: 1.0 References: <20210820010403.946838-1-joshdon@google.com> <20210820010403.946838-4-joshdon@google.com> In-Reply-To: From: Jiang Biao Date: Wed, 25 Aug 2021 10:43:56 +0800 Message-ID: Subject: Re: [PATCH v3 3/4] sched: reduce sched slice for SCHED_IDLE entities To: Josh Don Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Paul Turner , Oleg Rombakh , Viresh Kumar , Steve Sistare , Tejun Heo , Rik van Riel , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Aug 2021 at 01:04, Josh Don wrote: > > Hi Jiang, > > On Tue, Aug 24, 2021 at 3:25 AM Jiang Biao wrote: > > > > Why not just ignore min granularity when normal entities compete with > > a SCHED_IDLE entity? something like this, > > > > @@ -697,8 +710,14 @@ static u64 sched_slice(struct cfs_rq *cfs_rq, > > struct sched_entity *se) > > slice = __calc_delta(slice, se->load.weight, load); > > } > > > > - if (sched_feat(BASE_SLICE)) > > - slice = max(slice, (u64)sysctl_sched_min_granularity); > > + if (sched_feat(BASE_SLICE) > > + && (!se_is_idle(init_se) || sched_idle_cfs_rq(cfs_rq))) > > + slice = max(slice, (u64)sysctl_sched_min_granularity); > > > > return slice; > > } > > If so, there seems no need to introduce sysctl_sched_idle_min_granularity? :) > > Ignoring min_gran entirely could lead to some really tiny slices; see > discussion at https://lkml.org/lkml/2021/8/12/651. Got it, tiny slices could be a problem in SCHED_HRTICK case. But the sysctl_sched_idle_min_granularity used in sched_slice() and sysctl_sched_min_granularity used in check_preempt_tick would have different semantics for SCHED_IDLE task, which could be functional ok but a little confusing. Regards, Jiang