Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1128345ybz; Thu, 16 Apr 2020 03:29:42 -0700 (PDT) X-Google-Smtp-Source: APiQypKCefWHSboofoOwxKDhXHQWvzEvAeMD5ebc9fx0tdrrDxLu9t5VYFDog0tbPLQp61KCbvd7 X-Received: by 2002:aa7:d614:: with SMTP id c20mr29987191edr.232.1587032982278; Thu, 16 Apr 2020 03:29:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587032982; cv=none; d=google.com; s=arc-20160816; b=sepczu10nwwYb6mMfBV+D5ept/zWixT+V6rE/Q3mgRHttSAoDAYyOiBIEXX3LFdsCe avJraJu8f+Z2y88GOB1CXJZZ5WE18zS33FbpXg/CMeUI0DRsY8MvYjH+GEvOe7UyGxnx lDU3DIOh/6/8wr9lYz2OqFOPj0Zp2x7GS5WlOvgHPvwZwNLTRzDypzzVSFtA9lwxe6nv rqp95VbO3uNJYwPzrqC9rJuLvulGtZGfDV0hKkSDd9GSrrZwMokNI/aLU/A2G3dhTqZl Z25uQ7rHD3uiiOsdUt4nDy1UGXPmYNV8C4JI7OR/cEuwbpHuW+YuAco7LVoWcCR9y7Ui +SMg== 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=SOUwSIi67YFYm+IrKRkBBKwxkL7XHeWPQApO43Bb3dc=; b=d3PD2RTQnwiw5CGhJh5vrKwBDJ1eeXkKQc8lCiNHMmp4r6Wxtnp7FyKogYKdoXtzDa ddaGp2dGvXPfxGceidXId61OHF/zvCR18BZM/Y+xz4h/wBXUlgAIT+qTq+3JzOCeUqvO JCiA5wAupStBQP/Z+aKzsnDlHPZd0Oicb8kH3BT7EKWfvv8YvfdTRu3Fg2vwTFtce9wD i7UCm2JSsiZuqZnGqPou1yVRM8aYfdZ47iiHbhyp14zhIWvMejfZ9nX0MXHIGtfh0eiC +Y1tcF7gkpLwwTaxdXEf/0MQo+ulVt9d0RQmKML3mtrcWBY5Gz1UY3buYLM7MpszTlkf yz5A== 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 q18si4717837eju.4.2020.04.16.03.29.19; Thu, 16 Apr 2020 03:29:42 -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 S2504835AbgDPKZM (ORCPT + 99 others); Thu, 16 Apr 2020 06:25:12 -0400 Received: from foss.arm.com ([217.140.110.172]:58462 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2504821AbgDPKYf (ORCPT ); Thu, 16 Apr 2020 06:24:35 -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 A63C1C14; Thu, 16 Apr 2020 03:24:16 -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 865253F73D; Thu, 16 Apr 2020 03:24:15 -0700 (PDT) References: <20200415210512.805-1-valentin.schneider@arm.com> <20200415210512.805-7-valentin.schneider@arm.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Vincent Guittot Cc: linux-kernel , Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , Ingo Molnar , Juri Lelli , Steven Rostedt Subject: Re: [PATCH v3 6/9] sched: Kill select_task_rq()'s sd_flag parameter In-reply-to: Date: Thu, 16 Apr 2020 11:24:08 +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 Vincent, Thanks for taking a look at this. On 16/04/20 08:42, Vincent Guittot wrote: >> @@ -6622,13 +6622,25 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) >> * preempt must be disabled. >> */ >> static int >> -select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_flags) >> +select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags) >> { >> + int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING); >> struct sched_domain *tmp, *sd = NULL; >> int cpu = smp_processor_id(); >> int new_cpu = prev_cpu; >> int want_affine = 0; >> - int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING); >> + int sd_flag; >> + >> + switch (wake_flags & (WF_TTWU | WF_FORK | WF_EXEC)) { > > You remove a function parameter, which was directly set with the right > flag, but then you add a switch case to recreate this sd_flag > internally. Not sure we can say that it's real benefit > It is indeed the contentious point of this series (IMO). Still, it has a few things going for it: 1) only CFS is helped by that extra parameter 2) with patch 9, I need a control flow to pick up the right cached pointer anyway; the alternative would be to do something like the unsavoury: DEFINE_PER_CPU(struct sched_domain __rcu *, sd_balance_flags[3]); ... update_top_cache_domain() { per_cpu(sd_balance_flags[0], cpu) = highest_flag_domain(cpu, SD_BALANCE_EXEC); per_cpu(sd_balance_flags[1], cpu) = highest_flag_domain(cpu, SD_BALANCE_FORK); per_cpu(sd_balance_flags[2], cpu) = highest_flag_domain(cpu, SD_BALANCE_WAKE); } ... select_task_rq_fair() { // Whatever sort of shady constant time conversion you can think of int index = !!(wake_flags & WF_FORK) + 2 * !!(wake_flags & WF_TTWU) sd_flag = SD_BALANCE_EXEC << index; sd = per_cpu(sd_balance_flags[index], cpu); } >> + case WF_TTWU: >> + sd_flag = SD_BALANCE_WAKE; >> + break; >> + case WF_FORK: >> + sd_flag = SD_BALANCE_FORK; >> + break; >> + default: >> + sd_flag = SD_BALANCE_EXEC; >> + } >> >> if (sd_flag & SD_BALANCE_WAKE) { >> record_wakee(p);