Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2635515pxb; Tue, 21 Sep 2021 04:29:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzy8nA6cjmcRyEae2Qlahn2j0ELPhRdtdnhBlBSpJ9Xe3vuYAoVpNwsf8pitl44Nh54Dtxx X-Received: by 2002:a17:907:7755:: with SMTP id kx21mr33708812ejc.463.1632223741531; Tue, 21 Sep 2021 04:29:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632223741; cv=none; d=google.com; s=arc-20160816; b=0NVuLgTegm/QO6fEhPxlSP6MxaPnYMTONicrp5Rybc0MhDwMzt9wcXqvEBaaDSQrYh QZ576kPINQtZvsUQ5xXdo1NuRu0ks7uM7VeBwf5CM2qxrtVKXcUSUsijnfzhiRa3zwrR h3hypcDhd7tPnAKSMOCBzWbKNz1akML4jmjADdqMlQsN1NmYFeoCgu7Uy5J70/t2LR6p 97BywnN549+9BNVSrVbYKVvGXpLn1RJBycbiUyvrQ/JcRkJK9LzPPNmT3OHBWSlMyy4e UJX21c06dGYtpjuLhOQXUZQ32rfwXy2n79A+sBuL3oJXHJG01s+yMh5zAlX8khm53SQy ziVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=cRi/30sa8kbFws8k7vVIUwp5vTOcr6yBdWZ5XFkDuCE=; b=yHbVho2rAiM1A1xYqqr9US4U/z4o0LVdshBPuSgtBaRlLdi/X0oLl1JOqtizZ78o7U 8fbqNylpB0cNa4hwdk+2an/D6vHOdb8oGvYTIAxZiwe6CUwfs13/ftkrtBT9PuisUrA1 NOwwxuupPB5cvSSVgtKLspU1engYIQ2B8T3oE/wBciSZ2EXPaXLQPbL7CW0GlfGP6+dV wYTGsOnL+4oMRK1+8e4/xS9euTmSOOSVrAwTuFx/GPKT4z7OAGRuRP4R79hnh8ym7eN+ +mxdFz3+Su49Y2ZQ+4D9vIYpRiI/gxlA+RLB0bDNty6TtSNg5OvH2EONDd2YZaR83RGo +E3g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hg10si18570439ejc.344.2021.09.21.04.28.35; Tue, 21 Sep 2021 04:29:01 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231804AbhIUKqu (ORCPT + 99 others); Tue, 21 Sep 2021 06:46:50 -0400 Received: from outbound-smtp30.blacknight.com ([81.17.249.61]:43698 "EHLO outbound-smtp30.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231189AbhIUKqt (ORCPT ); Tue, 21 Sep 2021 06:46:49 -0400 Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp30.blacknight.com (Postfix) with ESMTPS id 93D6F1800A for ; Tue, 21 Sep 2021 11:45:20 +0100 (IST) Received: (qmail 6161 invoked from network); 21 Sep 2021 10:45:20 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.29]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Sep 2021 10:45:20 -0000 Date: Tue, 21 Sep 2021 11:45:18 +0100 From: Mel Gorman To: Vincent Guittot Cc: Peter Zijlstra , Ingo Molnar , Valentin Schneider , Aubrey Li , Barry Song , Srikar Dronamraju , LKML Subject: Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running Message-ID: <20210921104518.GN3959@techsingularity.net> References: <20210920142614.4891-1-mgorman@techsingularity.net> <20210920142614.4891-3-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 21, 2021 at 10:03:56AM +0200, Vincent Guittot wrote: > On Mon, 20 Sept 2021 at 16:26, Mel Gorman wrote: > > > > Commit 8a99b6833c88 ("sched: Move SCHED_DEBUG sysctl to debugfs") moved > > the kernel.sched_wakeup_granularity_ns sysctl under debugfs. One of the > > reasons why this sysctl may be used may be for "optimising for throughput", > > particularly when overloaded. The tool TuneD sometimes alters this for two > > profiles e.g. "mssql" and "throughput-performance". At least version 2.9 > > does but it changed in master where it also will poke at debugfs instead. > > > > During task migration or wakeup, a decision is made on whether > > to preempt the current task or not. To limit over-scheduled, > > sysctl_sched_wakeup_granularity delays the preemption to allow at least 1ms > > of runtime before preempting. However, when a domain is heavily overloaded > > (e.g. hackbench), the degree of over-scheduling is still severe. This is > > sysctl_sched_wakeup_granularity = 1 msec * (1 + ilog(ncpus)) > AFAIK, a 2-socket CascadeLake has 56 cpus which means that > sysctl_sched_wakeup_granularity is 6ms for your platform > On my machine it becomes 7ms but lets assume there were 56 cpus to avoid confusion. > > problematic as a lot of time can be wasted rescheduling tasks that could > > instead be used by userspace tasks. > > > > This patch scales the wakeup granularity based on the number of running > > tasks on the CPU up to a max of 8ms by default. The intent is to > > This becomes 8*6=48ms on your platform which is far more than the 15ms > below. Also 48ms is quite a long time to wait for a newly woken task > especially when this task is a bottleneck. > With the patch on top I proposed to Mike to take FAIR_SLEEPERS into account, it becomes ((sysctl_sched_latency / gran) >> 1) by default which becomes 18ms for heavy overloading or potentially 12ms if there is enough load to stack 2 tasks. The patch generates a warning as I didn't even build test it, but hey, it was for illustrative purposes. Is that any better conceptually or should we ignore the problem? My motivation here really is to reduce the motivation of others to "tune" debugfs values or be tempted to revert the move to debugfs. -- Mel Gorman SUSE Labs