Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6108644ybv; Tue, 18 Feb 2020 10:04:18 -0800 (PST) X-Google-Smtp-Source: APXvYqxTnqLTusrn0QEIKbTV5leoHWBqGOy3Sj2zbyv1qOkfLPkcRtYGg7x+4zp7bpdw15DIXyRq X-Received: by 2002:aca:220c:: with SMTP id b12mr1970603oic.55.1582049058204; Tue, 18 Feb 2020 10:04:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582049058; cv=none; d=google.com; s=arc-20160816; b=BuKlASIenrXYj4pxPQVOaDI3eM11EzM+6GeXSnq1CDF7TdLvmkPmFj98YZMTtsDTP4 N88j4rhJPAIXIZhe4I6Wci/H2a38LmEZDqITb+3COInw+HPPO8RVcJDpzMcSPHH1ZNvL NwASkLfGUHaJKTGVYz0Bq08eHJnjYgyIDidKPfPtjNgjdKSs2SX9b1tv6795AtE+KFmp 36hPiNJia4CQMB2YQ4U8l+02VQxQavE26oFincw7gJaEuTNAqrtHiavpgGFQ9W15JeCS L3sRYCg6bXdnWsbi+8+QIP64sNuTQNCEP+lqasBwtLhKg8/vgxI007z7YrBdiCh9bYIM H1zw== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=15flnbjsvmqBQXCEyVX1KnoMeVmuipK2mkvy6hHKayo=; b=n6o8dQnNZ07IPp5lffvZnFiB+H0fTueJ7XxPMD9avxxiL9S2QKzAWb2pnlnZXKMHGj SJGXGTvGmt+SUavZbvWUIthNCxsRMg2/3Au42nCmzqZ8g7i36I9ZoTW5t0bYImDCZZCc MosZYPZpLdKBwOH60AIsZ+bNEksLpSiMASLdVKbiO4ZiuvoF+cRdBRElf+dvASs8Xpx9 ECZJFJzLIXJWRYk8PV7TiNYF8nLWzHRXpFMaIVVquiSf8G4HXL1mmeoy1LfliQNCp23n 9kiugVXVkJkDZQZWTrEHRC/Dhc2Hv7qPdTeDIjODqKHq81mtTWWEJ9WHXkhOCvgE4Oyr ohqQ== 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 l21si8507536oic.126.2020.02.18.10.04.04; Tue, 18 Feb 2020 10:04:18 -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 S1726546AbgBRSDD (ORCPT + 99 others); Tue, 18 Feb 2020 13:03:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:39188 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726403AbgBRSDD (ORCPT ); Tue, 18 Feb 2020 13:03:03 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2714C2070B; Tue, 18 Feb 2020 18:03:02 +0000 (UTC) Date: Tue, 18 Feb 2020 13:03:00 -0500 From: Steven Rostedt To: Qais Yousef Cc: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Pavan Kondeti , Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] sched/rt: cpupri_find: implement fallback mechanism for !fit case Message-ID: <20200218130300.679f77ea@gandalf.local.home> In-Reply-To: <20200218172745.hd7fxjqnzqkhfqx3@e107158-lin.cambridge.arm.com> References: <20200214163949.27850-1-qais.yousef@arm.com> <20200214163949.27850-2-qais.yousef@arm.com> <20200217234549.rpv3ns7bd7l6twqu@e107158-lin> <20200218114658.74236b3c@gandalf.local.home> <20200218172745.hd7fxjqnzqkhfqx3@e107158-lin.cambridge.arm.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 Feb 2020 17:27:46 +0000 Qais Yousef wrote: > > If we are going to use static branches, then lets just remove the > > parameter totally. That is, make two functions (with helpers), where > > one needs this fitness function the other does not. > > > > if (static_branch_unlikely(&sched_asym_cpu_capacity)) > > ret = cpupri_find_fitness(...); > > else > > ret = cpupri_find(...); > > > > if (!ret) > > return -1; > > > > Something like that? > > Is there any implication on code generation here? > > I like my flavour better tbh. But I don't mind refactoring the function out if > it does make it more readable. I just figured we remove the passing of the parameter (which does make an impact on the code generation). Also, perhaps it would be better to not have to pass functions to the cpupri_find(). Is there any other function that needs to be past, or just this one in this series? -- Steve