Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4955780ybv; Mon, 17 Feb 2020 09:10:15 -0800 (PST) X-Google-Smtp-Source: APXvYqz53LuU8ouyOdRDdqTs5tEN93bgK2XvLL2bkj7TfKGvZbGgNRMpihe/oXxq3Hj1A4TG8XIz X-Received: by 2002:a05:6830:16d8:: with SMTP id l24mr12928506otr.268.1581959415485; Mon, 17 Feb 2020 09:10:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581959415; cv=none; d=google.com; s=arc-20160816; b=FGsXwORhHHofu7wr3fFZ0wry2GmeRI8U7advGhXBTNo9pPBz3p9h/E1yWcjcVL/Cqk 75yL4H3E6SJg+kRYWBzIyLhAsLbcpt1MfIgC5VCS65OzCfs2E2o+8aBELJFaOaTnamcV VJroOl/F/EBefqLv8wWXyIDk8JvROW8A6muBNxt5vGz70pIF9RVrYwR1ltP/6uteGD2y 3gKV2W6QMD4bOHZ6qOiljjpqzuxl5bBfReJ0+bYWcTFpOoZAwfPeE+MD6xfOUGnYT0N8 Skul2G/4z1Iv/4xep8DS8PQLHa3MEBxAnPbInnAydaiB3RTVBndp2hJdVTHb5Vxxmin7 EGSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=H7uo+oaBH7bLMI9CvSviJ8nUuOk67j3ZYAvj4JnUG4k=; b=MyalPQGVvyelqmSeL2ZkkqQ/witsY6Wy3XoYzL7kmQfKGq1PPfIYbA8ZMT0Oc3GNbg dY/KKf+zRmghBpSkXiCJymRYDpleZVwvPgK0om/nPW+7e9G6mMwETVxeMisYbQjdfUoR 4Ir4PIPxxbKZ04aL5JsUCF+fZo5bEyphXeN/VtNHH4tf3Wa/QOtjb/e9X80+jcWUZ1EL SN2/7VNadokqCcfuN0tMYz/dF0aBAzsogddvYQ7UaEdC9+NCOf8y/GVq3WNoVbbjjjZO VNyM/WTpYZfnXohgM4JtILwSqQCBEGMrRxbVOxiCso4U2FWK7i+Y+4DFmPejLvQMsPJ1 YevQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w13si6801604oiw.106.2020.02.17.09.10.03; Mon, 17 Feb 2020 09:10:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729316AbgBQRHr (ORCPT + 99 others); Mon, 17 Feb 2020 12:07:47 -0500 Received: from foss.arm.com ([217.140.110.172]:38866 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729257AbgBQRHq (ORCPT ); Mon, 17 Feb 2020 12:07:46 -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 AC9981FB; Mon, 17 Feb 2020 09:07:45 -0800 (PST) Received: from [10.1.195.59] (ifrit.cambridge.arm.com [10.1.195.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 52CCB3F68F; Mon, 17 Feb 2020 09:07:44 -0800 (PST) Subject: Re: [PATCH 1/3] sched/rt: cpupri_find: implement fallback mechanism for !fit case To: Qais Yousef , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Pavan Kondeti , Dietmar Eggemann Cc: Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org References: <20200214163949.27850-1-qais.yousef@arm.com> <20200214163949.27850-2-qais.yousef@arm.com> From: Valentin Schneider Message-ID: <3feb31bb-3412-b38c-07a3-136433c87e66@arm.com> Date: Mon, 17 Feb 2020 17:07:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200214163949.27850-2-qais.yousef@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/14/20 4:39 PM, Qais Yousef wrote: > When searching for the best lowest_mask with a fitness_fn passed, make > sure we record the lowest_level that returns a valid lowest_mask so that > we can use that as a fallback in case we fail to find a fitting CPU at > all levels. > > The intention in the original patch was not to allow a down migration to > unfitting CPU. But this missed the case where we are already running on > unfitting one. > > With this change now RT tasks can still move between unfitting CPUs when > they're already running on such CPU. > > And as Steve suggested; to adhere to the strict priority rules of RT, if > a task is already running on a fitting CPU but due to priority it can't > run on it, allow it to downmigrate to unfitting CPU so it can run. > > Reported-by: Pavan Kondeti > Signed-off-by: Qais Yousef > --- > kernel/sched/cpupri.c | 157 +++++++++++++++++++++++++++--------------- > 1 file changed, 101 insertions(+), 56 deletions(-) > > diff --git a/kernel/sched/cpupri.c b/kernel/sched/cpupri.c > index 1a2719e1350a..1bcfa1995550 100644 > --- a/kernel/sched/cpupri.c > +++ b/kernel/sched/cpupri.c > @@ -41,6 +41,59 @@ static int convert_prio(int prio) > return cpupri; > } > > +static inline int __cpupri_find(struct cpupri *cp, struct task_struct *p, > + struct cpumask *lowest_mask, int idx) > +{ > + struct cpupri_vec *vec = &cp->pri_to_cpu[idx]; > + int skip = 0; > + > + if (!atomic_read(&(vec)->count)) > + skip = 1; > + /* > + * When looking at the vector, we need to read the counter, > + * do a memory barrier, then read the mask. > + * > + * Note: This is still all racey, but we can deal with it. > + * Ideally, we only want to look at masks that are set. > + * > + * If a mask is not set, then the only thing wrong is that we > + * did a little more work than necessary. > + * > + * If we read a zero count but the mask is set, because of the > + * memory barriers, that can only happen when the highest prio > + * task for a run queue has left the run queue, in which case, > + * it will be followed by a pull. If the task we are processing > + * fails to find a proper place to go, that pull request will > + * pull this task if the run queue is running at a lower > + * priority. > + */ > + smp_rmb(); > + > + /* Need to do the rmb for every iteration */ > + if (skip) > + return 0; > + > + if (cpumask_any_and(p->cpus_ptr, vec->mask) >= nr_cpu_ids) > + return 0; > + > + if (lowest_mask) { > + cpumask_and(lowest_mask, p->cpus_ptr, vec->mask); > + > + /* > + * We have to ensure that we have at least one bit > + * still set in the array, since the map could have > + * been concurrently emptied between the first and > + * second reads of vec->mask. If we hit this > + * condition, simply act as though we never hit this > + * priority level and continue on. > + */ > + if (cpumask_empty(lowest_mask)) > + return 0; > + } > + > + return 1; > +} > + Just a drive-by comment; could you split that code move into its own patch? It'd make the history a bit easier to read IMO.