Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4349622pxb; Tue, 5 Oct 2021 00:49:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz16nkH6GgJye/36NASu40Hsr7rM96c8Kg3ZedpqKNrSfmKKYNOSiaxysKkm3XHewLO+XO4 X-Received: by 2002:a65:6648:: with SMTP id z8mr14859498pgv.418.1633420164277; Tue, 05 Oct 2021 00:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633420164; cv=none; d=google.com; s=arc-20160816; b=OU3hOkUexzJRn+8RHF96E2UYasqPXMtrzKfsObCk3z7KfhII7gB+fWpzoa2McycXY7 eYO6Fx3JDzme8F4XKcbG3/zhBJ0FUIodQhEU9n5V7SG7j89XeelW6Cz7Yfd6VWQ+BUmb ZUCOX/CBcqMM6KDwP2eUbGtXyG0uUl/25fVwFaD4g0eJNpHrAs6Iqy/L3+S8o9Hzo63C /n1s2ZtmSlUlwsqQBpzFVJ6QwgVXDUP4oI6I5cS8xSkUxzNWz2tQvYARLcvAC2KPXVqc C0ZWV5H6W44DRBRTeIW/cFeYwmbCP3gMXe+lwJHU1kmpR3QwP8ws2iWJqLZPlW0ig0Hy OcRw== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Woh34x1glzfJWNV2RvgLqW2KSEBfRPaI/CpHC4X9OrY=; b=XwwumVk8exi4AHcQIw3HPc8zmqvCnN6++vD9UYkS0WnlNz8B5CJlLzQ8O5uQEJB9JY D7fLTQOq+n2jQeRRINN3PENzrzNsgOg9hKEwV/0ZguvngyNObJU4phxiFKfs2zr8xufk chXYzN0sok6PeQ03lSgjI+WSfELxXK8+gY0UNOxSW3GQA0ux1utt4fqJySXRFVKJRkCI bwb9azS+QF25ZqvYbBAJcj1yuiv0XVQ2DIFO8ZYapCq8MuM0D3QIkLh+VoyqaUqu35w1 3WTDpBhbAp4TEh+1LYe868Xsm2AovaYA9v5yz/uIxBm6njseOzNUvgXsHjkkh//l4YlM ocQA== 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 j7si29835759plx.296.2021.10.05.00.49.11; Tue, 05 Oct 2021 00:49:24 -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 S232871AbhJEHtP (ORCPT + 99 others); Tue, 5 Oct 2021 03:49:15 -0400 Received: from outbound-smtp02.blacknight.com ([81.17.249.8]:56333 "EHLO outbound-smtp02.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232888AbhJEHtN (ORCPT ); Tue, 5 Oct 2021 03:49:13 -0400 Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp02.blacknight.com (Postfix) with ESMTPS id F060BF60E1 for ; Tue, 5 Oct 2021 08:47:20 +0100 (IST) Received: (qmail 9913 invoked from network); 5 Oct 2021 07:47: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); 5 Oct 2021 07:47:20 -0000 Date: Tue, 5 Oct 2021 08:47:19 +0100 From: Mel Gorman To: Mike Galbraith Cc: Barry Song <21cnbao@gmail.com>, Peter Zijlstra , Ingo Molnar , Vincent Guittot , Valentin Schneider , Aubrey Li , Barry Song , Srikar Dronamraju , LKML Subject: Re: wakeup_affine_weight() is b0rked - was Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running Message-ID: <20211005074719.GP3959@techsingularity.net> References: <20210920142614.4891-1-mgorman@techsingularity.net> <20210920142614.4891-3-mgorman@techsingularity.net> <22e7133d674b82853a5ee64d3f5fc6b35a8e18d6.camel@gmx.de> <20210921103621.GM3959@techsingularity.net> <02c977d239c312de5e15c77803118dcf1e11f216.camel@gmx.de> <4f571c5c759b9d356d1bb4114fb169181194a780.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4f571c5c759b9d356d1bb4114fb169181194a780.camel@gmx.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 04, 2021 at 11:06:30AM +0200, Mike Galbraith wrote: > On Mon, 2021-10-04 at 06:34 +0200, Mike Galbraith wrote: > > On Sun, 2021-10-03 at 20:34 +1300, Barry Song wrote: > > > > > > I am wondering if this should be the responsibility of wake_wide()? > > > > Those event threads we stacked so high (which are kde minions btw), > > don't generally accrue _any_ wakee_flips, so when X wakes a slew of the > > things, wake_wide()'s heuristic rejects the lot. > > > > So yeah, the blame game for this issue is a target rich environment. > > Shoot either of 'em (or both), and you'll hit the bad guy. > > The mallet below convinced wake_wide() that X waking event threads is > something it most definitely should care about. It's not perfect, can > get caught with its pants down, because behavior changes a LOT, but I > at least have to work at it a bit to stack tasks to the ceiling. > > With make -j8 running along with firefox with two tabs, one containing > youtube's suggestions of stuff you probably don't want to watch, the > other a running clip, if I have the idle tab in focus, and don't drive > mouse around, flips decay enough for wake_wide() to lose interest, but > just wiggle the mouse, and it starts waking wide. Focus on the running > clip, and it continuously wakes wide. ? > > Hacky, but way better behavior.. at this particular testcase.. in this > particular box.. at least once :) > Only three machines managed to complete tests overnight. For most workloads test, it was neutral or slight improvements. For multi-kernbench__netperf-tcp-rr-multipair (kernel compile + netperf-tcp-rr combined), there was little to no change. For the heavy overloaded cases (hackbench again), it was variable. Worst improvement was a gain of 1-3%. Best improvement (single socket skylake with 8 logical CPUs SMT enabled) was 1%-18% depending on the group count. -- Mel Gorman SUSE Labs