Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp599374ybz; Wed, 15 Apr 2020 14:53:31 -0700 (PDT) X-Google-Smtp-Source: APiQypIOEiQCPth3MVBWUmu5qHYPUrFHx3lNO/JiZeIIJR76UBvMMRlaQWFuDwYOzxzTAn8nDWBo X-Received: by 2002:a50:cd89:: with SMTP id p9mr26916343edi.188.1586987611199; Wed, 15 Apr 2020 14:53:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586987611; cv=none; d=google.com; s=arc-20160816; b=0D3Ajqz/mqnZtHJxepVZg9P11xdV0tPl12A7Mp9BKzs/J+VHH2rFiRPhHyxcXlhnfr iPehc7VvoiIvjCAquzCQita/4zwGxtwLQWlo1CY6i50vYVD6bgzfDNdttRIXEG5hVOBg CZaX7u3lnBmY5ULQ5L61fWsFnqypVcu4r8IT/2QhJ97JJKpJchHJaIsADwkTP9F2RSf1 lUzelpvbPw8J2lEWdqyAcMQA8kEq2vKcREQMLIuI1Rqx6c3uaDXz2rNXpMUEoO1TxQKY r+Oorw1u9JOFQ6R1xxuDu8fHOSH2hJ/UkgAWi0h8ujP9lirdQFlCoVpvBbcFiMDirhNu hieQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=DpPO8pI8BbpaSQHwW+b1IUYWZ1svBv2q6yn8A7gh/iE=; b=uY9HKxDqj7OlmrabeU8MOnnlkb0Q/meaVe/JBm9NZC+TOGpylVDOf+zPmvoGF6QVrP CPRr9Or6DQQfkC6vKgI29vjlWWqmLQ/6NDoNtK+oVJ4mm6LobTUbjNZCpH/veSP4lpWv WW/9ui4JqL98ek5m3NRJaZ267N38L00uYsxOcQ3C/TyoFkvY5zlNBuxv5JblVQfcyBX/ xAHJurLQEIZSzNHpYqzzwNohgvzg5d7WsRBPLOQTljqQq67qr8VQTlf78gdai5bdxKiB E9X3YJrlKntapxilEvk+Ps7fI/kQsIuBm96I9IzFZ9/+FSTVHmcx6Dglr92X0d+S0fGJ u5oQ== 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 u22si11718392eja.142.2020.04.15.14.53.07; Wed, 15 Apr 2020 14:53:31 -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 S2504550AbgDNS7R (ORCPT + 99 others); Tue, 14 Apr 2020 14:59:17 -0400 Received: from foss.arm.com ([217.140.110.172]:33388 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2504532AbgDNS7A (ORCPT ); Tue, 14 Apr 2020 14:59:00 -0400 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 62C6A1FB; Tue, 14 Apr 2020 11:58:57 -0700 (PDT) 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 4AF3D3F68F; Tue, 14 Apr 2020 11:58:55 -0700 (PDT) References: <20200414150556.10920-1-qais.yousef@arm.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Andrew Morton , Thomas Gleixner , Yury Norov , Paul Turner , Alexey Dobriyan , Josh Don , Pavan Kondeti , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq() In-reply-to: <20200414150556.10920-1-qais.yousef@arm.com> Date: Tue, 14 Apr 2020 19:58:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 14/04/20 16:05, Qais Yousef wrote: > Now that we have a proper function that returns a 'random' CPU in a mask [1] > utilize that in find_lowest_rq() to solve the thundering herd issue described > in this thread > > https://lore.kernel.org/lkml/20200219140243.wfljmupcrwm2jelo@e107158-lin/ > > But as a pre-amble, I noticed that the new cpumask_any_and_distribute() is > actually an alias for cpumask_any_and() which is documented as returning > a 'random' cpu but actually just does cpumask_first_and(). > > The first 3 patches cleanup the API so that the whole family of > cpumask_any*() take advantage of the new 'random' behavior I'm a bit wary about such blanket changes. I feel like most places impacted by this change don't gain anything by using the random thing. In sched land that would be: - The single cpumask_any() in core.c::select_task_rq() - Pretty much any function that wants a CPU id to dereference a root_domain; there's some of them in deadline.c, topology.c Looking some more into it, there's shadier things: - cpufreq_offline() uses cpumask_any() to figure out the new policy leader... That one should be cpumask_first() - gic_set_affinity() uses cpumask_any_and() (in the common case). If this starts using randomness, you will stop affining e.g. all SPIs to CPU0 by default (!!!) - ... and there might be more I think people went with cpumask_any_* mostly because there is just cpumask_first() while there are more cpumask_any_* variants, and since those have been returning the first set CPU for over a decade people just went with it. To move this forward, I would suggest renaming the current cpumask_any_*() into cpumask_first_*(), and THEN introduce the new pseudo-random ones. People are then free to hand-fix specific locations if it makes sense there, like you're doing for RT. I think it's safe to say the vast majority of the current callers do not require randomness - the exceptions should mainly be scheduler / workqueues and the like. > and in patch > 4 I convert the cpumask_first_and() --> cpumask_any_and() in find_lowest_rq() > to allow to better distribute the RT tasks that wake up simultaneously. > > [1] https://lore.kernel.org/lkml/20200311010113.136465-1-joshdon@google.com/ > > CC: Juri Lelli > CC: Vincent Guittot > CC: Dietmar Eggemann > CC: Steven Rostedt > CC: Ben Segall > CC: Mel Gorman > CC: Andrew Morton > CC: Thomas Gleixner > CC: Yury Norov > CC: Paul Turner > CC: Alexey Dobriyan > CC: Josh Don > CC: Pavan Kondeti > CC: linux-kernel@vger.kernel.org > > Qais Yousef (4): > cpumask: Rename cpumask_any_and_distribute > cpumask: Make cpumask_any() truly random > cpumask: Convert cpumask_any_but() to the new random function > sched/rt: Better distribute tasks that wakeup simultaneously > > include/linux/cpumask.h | 33 ++++++----------- > kernel/sched/core.c | 2 +- > kernel/sched/rt.c | 4 +- > lib/cpumask.c | 82 +++++++++++++++++++++++++++-------------- > 4 files changed, 68 insertions(+), 53 deletions(-)