Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1575609pxb; Fri, 6 Nov 2020 13:23:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxqu9tqm1nIaqGXvijXMFiq1J4ARRgN9yHFITRwr2dUrIq3Nvn1aeqbZQJUISAXWAZQmmjw X-Received: by 2002:aa7:c9c3:: with SMTP id i3mr4218931edt.236.1604697781145; Fri, 06 Nov 2020 13:23:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604697781; cv=none; d=google.com; s=arc-20160816; b=QHcoOfFFznIbhfO0L+vp8VH+gJf+22uF4xMTAIswBIq1dOTA/pGg+ZrWnU5g5arAfj k2I8BMD+416BsDbrcDrklJsfx/nO2AQnmsL/8m0xTyT8VaTeVBcadgjJeVYm12ig6B7m Mjpb8AyYoAlfGG7AiZvQzJ2HmQZqEQrGv/lSSBPiF+FzS1pFUs8b9wSy/HmPQoCI4YOM EVvTGOsJSIL1encVw75rhXk+1OFn9g0hvoo5Nfj76Law8Spdkuo1uSCM2S7HyMofA4AA p5+qOkRGDIS+6psAJT4GL37O6EA5vnSARTKS2hXaOFXGAkuRPSujrUZelyhn+brQ5O/7 W1OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:date:in-reply-to:message-id:subject :cc:to:from:user-agent:references; bh=8FxCoVB3ShbOl0q2hJvUJ/O7zmntRp8sUT3ptiZZNIk=; b=dhz8dpuC1Ox2T/4wv9zBKNLIlviLr5473l/FJMikOExXNqKXR/BIuD7OeU7uEhljVS COJhbUPJr7zz27kgNMcHh2Ocxs3bR92e/WFxwlW4OYwAASa0X0kNk83PNvVa2jnld8HK Av/8FtTnNp8dgVV8JmRxL+mXH2PIKqilWgdt94tKD7fP6oijL4G961UkLaYdp0hh8YRH KEkVdK16yzbDiJ8+MiJZVWD5L7nDY4PK7wM+6veJz91RxVnCjxuWloEftTlbM3/a7WJU CqJ7qZJdNsS24wIxPHglXvPTdeiyFHMhAjcBWqaevrylWeQBv3akbSJ1PqD/Bakilem5 dNLg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gh19si1628266ejb.526.2020.11.06.13.22.36; Fri, 06 Nov 2020 13:23:01 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727591AbgKFVUT (ORCPT + 99 others); Fri, 6 Nov 2020 16:20:19 -0500 Received: from foss.arm.com ([217.140.110.172]:44882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726415AbgKFVUT (ORCPT ); Fri, 6 Nov 2020 16:20:19 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C85D61474; Fri, 6 Nov 2020 13:20:17 -0800 (PST) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09AA73F718; Fri, 6 Nov 2020 13:20:15 -0800 (PST) References: <20201021150335.1103231-1-aubrey.li@linux.intel.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Aubrey Li Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org, Aubrey Li , Qais Yousef , Jiang Biao Subject: Re: [RFC PATCH v3] sched/fair: select idle cpu from idle cpumask for task wakeup Message-ID: In-reply-to: <20201021150335.1103231-1-aubrey.li@linux.intel.com> Date: Fri, 06 Nov 2020 21:20:05 +0000 MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/10/20 16:03, Aubrey Li wrote: > From: Aubrey Li > > Added idle cpumask to track idle cpus in sched domain. When a CPU > enters idle, its corresponding bit in the idle cpumask will be set, > and when the CPU exits idle, its bit will be cleared. > > When a task wakes up to select an idle cpu, scanning idle cpumask > has low cost than scanning all the cpus in last level cache domain, > especially when the system is heavily loaded. > FWIW I gave this a spin on my arm64 desktop (Ampere eMAG, 32 core). I get some barely noticeable (AIUI not statistically significant for bench sched) changes for 100 iterations of: | bench | metric | mean | std | q90 | q99 | |------------------------------------+----------+--------+---------+--------+--------| | hackbench --loops 5000 --groups 1 | duration | -1.07% | -2.23% | -0.88% | -0.25% | | hackbench --loops 5000 --groups 2 | duration | -0.79% | +30.60% | -0.49% | -0.74% | | hackbench --loops 5000 --groups 4 | duration | -0.54% | +6.99% | -0.21% | -0.12% | | perf bench sched pipe -T -l 100000 | ops/sec | +1.05% | -2.80% | -0.17% | +0.39% | q90 & q99 being the 90th and 99th percentile. Base was tip/sched/core at: d8fcb81f1acf ("sched/fair: Check for idle core in wake_affine") > v2->v3: > - change setting idle cpumask to every idle entry, otherwise schbench > has a regression of 99th percentile latency. > - change clearing idle cpumask to nohz_balancer_kick(), so updating > idle cpumask is ratelimited in the idle exiting path. > - set SCHED_IDLE cpu in idle cpumask to allow it as a wakeup target. > > v1->v2: > - idle cpumask is updated in the nohz routines, by initializing idle > cpumask with sched_domain_span(sd), nohz=off case remains the original > behavior. > > Cc: Mel Gorman > Cc: Vincent Guittot > Cc: Qais Yousef > Cc: Valentin Schneider > Cc: Jiang Biao > Cc: Tim Chen > Signed-off-by: Aubrey Li