Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp110837ybx; Wed, 30 Oct 2019 12:08:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqyAsEwP1kDMz+bZ9NHovGC0VRicNi4gmIY3Uoj4hmzaSuUtk8NoNWrEpBCs4aNhy3+QKIdO X-Received: by 2002:aa7:cd64:: with SMTP id ca4mr1442139edb.121.1572462489941; Wed, 30 Oct 2019 12:08:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572462489; cv=none; d=google.com; s=arc-20160816; b=VPBnvvpOxPozQpYnnu/56DuKzRpserBinHObBN3F+HYXJdZrn1ddXMfZ8WEV/mKYvk Gpykt0jOZbQLutEPOMUShtvhCiK95Etu2/U0Bi40w+6dpM1nkOEKHAdni+3t4dQBBvY8 xj16RkLSqgdqFsjVvamhCrRg8Y6sTP5gHlr4byRZogmgvHMkhzC0Nzc4lzsiX6uXywE6 ylCVDxidj/eHdEzYR5fyUWDEegVZVq15DRyxnlZUfZb/r2FkN8K42bR10FSwIO8Ommuj QIDQ76hTIzDrdvAu9eAEKYJh0S07Z2NYVWmctZNakS4gUU4WIOBkhLcYKrz9xFX66DZG kKwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=IKYpDnwC5hb5f2LWSNoR/dYrUtejn7TftVUNT7XxBpM=; b=uFuMvKyZUHJVh5kTl2afpekqELVO1PKv6PQJh685eIBnHY+cGGM9y8yAbWSvzHKJ8F gGX/2DgMHhYsSci4nkroYSkvaVDtlBIOQXt2srMHQgZwB4CpKUw3XD1hxlze+CBpgPA6 l2m+q0gmLLEr/z/0O8zAHQIoqG7ra36rINmLpWnJtKFWh8b4Tq6akK5/JE46l9pJjsV/ KW5stNNTuinK421OpT2CJUB4OGFEoFZJK9SY6Cav2fk5UWDb+K5B0g6zDJ5PTanFUy2W +7U4JMJWzAlqM/sEyVShYKZKZrRZwyK09bNKZvXJ1xvW2RQjoc88jvDuo7MCOXrwq/nU IoEA== 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 k63si2317796edc.347.2019.10.30.12.07.45; Wed, 30 Oct 2019 12:08:09 -0700 (PDT) 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 S1727085AbfJ3RnP (ORCPT + 99 others); Wed, 30 Oct 2019 13:43:15 -0400 Received: from foss.arm.com ([217.140.110.172]:38600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbfJ3RnP (ORCPT ); Wed, 30 Oct 2019 13:43:15 -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 7BC2B1FB; Wed, 30 Oct 2019 10:43:14 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 425273F6C4; Wed, 30 Oct 2019 10:43:13 -0700 (PDT) Date: Wed, 30 Oct 2019 17:43:10 +0000 From: Qais Yousef To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched: rt: Make RT capacity aware Message-ID: <20191030174309.buptfbqha374efpl@e107158-lin.cambridge.arm.com> References: <20191009104611.15363-1-qais.yousef@arm.com> <39c08971-5d07-8018-915b-9c6284f89d5d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <39c08971-5d07-8018-915b-9c6284f89d5d@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/30/19 12:57, Dietmar Eggemann wrote: > On 09.10.19 12:46, Qais Yousef wrote: > > [...] > > > Changes in v2: > > - Use cpupri_find() to check the fitness of the task instead of > > sprinkling find_lowest_rq() with several checks of > > rt_task_fits_capacity(). > > > > The selected implementation opted to pass the fitness function as an > > argument rather than call rt_task_fits_capacity() capacity which is > > a cleaner to keep the logical separation of the 2 modules; but it > > means the compiler has less room to optimize rt_task_fits_capacity() > > out when it's a constant value. > > I would prefer exporting rt_task_fits_capacity() sched-internally via > kernel/sched/sched.h. Less code changes and the indication whether > rt_task_fits_capacity() has to be used in cpupri_find() is already given > by lowest_mask being !NULL or NULL. > I don't mind if the maintainers agree too. The reason I did that way is because it keeps the implementation of cpupri generic and self contained. rt_task_fits_capacity() at the moment is a static function in rt.c To use it in cpupri_find() I either need to make it public somewhere or have an extern bool rt_task_fits_capacity(...); in cpupri.c. Neither of which appealed to me personally. > [...] > > > +inline bool rt_task_fits_capacity(struct task_struct *p, int cpu) > > +{ > > + unsigned int min_cap; > > + unsigned int max_cap; > > + unsigned int cpu_cap; > > Nit picking. Since we discussed it already, > > I found this "Also please try to aggregate variables of the same type > into a single line. There is no point in wasting screen space::" ;-) > > https://lore.kernel.org/r/20181107171149.165693799@linutronix.de That wasn't merged at the end AFAICT :) It's not my preferred style in this case if I have the choice - but I promise to change it if I ended up having to spin another version anyway :) > > [...] > > > @@ -2223,7 +2273,10 @@ static void switched_to_rt(struct rq *rq, struct task_struct *p) > > */ > > if (task_on_rq_queued(p) && rq->curr != p) { > > #ifdef CONFIG_SMP > > - if (p->nr_cpus_allowed > 1 && rq->rt.overloaded) > > + bool need_to_push = rq->rt.overloaded || > > + !rt_task_fits_capacity(p, cpu_of(rq)); > > + > > + if (p->nr_cpus_allowed > 1 && need_to_push) > > rt_queue_push_tasks(rq); > > #endif /* CONFIG_SMP */ > > if (p->prio < rq->curr->prio && cpu_online(cpu_of(rq))) > What happens to a always running CFS task which switches to RT? Luca > introduced a special migrate callback (next to push and pull) > specifically to deal with this scenario. A lot of new infrastructure for > this one use case, but still, do we care for it in RT as well? > > https://lore.kernel.org/r/20190506044836.2914-4-luca.abeni@santannapisa.it > Good question. This scenario and the one where uclamp values are changed while an RT task is running are similar. In both cases the migration will happen on the next activation/wakeup AFAICS. I am not sure an always running rt/deadline task is something conceivable in practice and we want to cater for. It is certainly something we can push a fix for in the future on top of this. IMHO we're better off trying to keep the complexity low until we have a real scenario/use case that justifies it. As it stands when the system is overloaded or when there are more RT tasks than big cores we're stuffed too. And there are probably more ways where we can shoot ourselves in the foot. Using RT and deadline is hard and that's one of their unavoidable plagues I suppose. Thanks -- Qais Yousef