Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1193840ybz; Thu, 16 Apr 2020 04:49:27 -0700 (PDT) X-Google-Smtp-Source: APiQypLdfMrdBooeu3v+1OWMkPXzGULeeLNZMTcBBfCZvRhouk8ZKCitoe3x+nc7aUR40IlwPW/1 X-Received: by 2002:aa7:d0d6:: with SMTP id u22mr13724047edo.262.1587037767537; Thu, 16 Apr 2020 04:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587037767; cv=none; d=google.com; s=arc-20160816; b=laUIwHtccDdaL1M7icGR8d8lwGL2Y+Vwji1VzbSGMlliCXsl010UBTFUaTH5hLGuF9 KZ2CjxETuxtwlhyPwwBeQwocn5yCYd7Lu1HoJmilwRE+bW6BJTCI2VpfbccDkUqJJBu/ noe9XxRS2OFsSs943/Lj0A6HavMkNJFxgKIp0ywG6jWUrSLR322hFDHW0KoVzy3I0IKo So3smfQH+HL0rNanJgYrFAdJZf350NarP1LYqE5bYtPzYOum0TfkHdHso2UW5YBoeixQ OtCqtfwHSzVDn9rY38TmIN8g+nzqd8LeL97mE+Nka/WsOq16RCWhzqfA3G6fJp5OYfuh mYwg== 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=VKqpzQYXD58A7K9MZ3wKFRtEvbFzA9sNJeBgbLxdf8w=; b=SiIczdXNKdThN6KUxsAt6PU1QJjMsWKEaJUvGZLSZR4FXnSPmgo3a53LCE7OVzFR/z R5Yel99AtjuJjB7s5FVo2cZJESzYGOhvX3LtJbmhw4+56EjxmSHyUB26vlg4BUMQS9F+ f1+yNr/P3U1GIWGr8lHioJqYVASzUhGlRMNXuF4/a44BKx9wUsjA1zX+7GA3fgjuRr76 R+0flv0e2imnagflWnqbvONrcw6JRpdt1Rnd2WLfY+TneJ34ACXYxD5yPOtaE/B915kh Dmc19aZu+W451ft74RroFkrYfGhL8oP7N/YgCf8i0ChhBoa37YjXFrdLA0YE+slH7CD2 doHg== 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 z1si13962413edp.464.2020.04.16.04.49.04; Thu, 16 Apr 2020 04:49:27 -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 S2504790AbgDPK00 (ORCPT + 99 others); Thu, 16 Apr 2020 06:26:26 -0400 Received: from foss.arm.com ([217.140.110.172]:58474 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2504822AbgDPKYg (ORCPT ); Thu, 16 Apr 2020 06:24:36 -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 A030B1063; Thu, 16 Apr 2020 03:24:23 -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 D69EC3F73D; Thu, 16 Apr 2020 03:24:22 -0700 (PDT) References: <20200415210512.805-1-valentin.schneider@arm.com> <20200415210512.805-10-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 Subject: Re: [PATCH v3 9/9] sched/topology: Define and use shortcut pointers for wakeup sd_flag scan In-reply-to: Date: Thu, 16 Apr 2020 11:24:20 +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 On 16/04/20 08:46, Vincent Guittot wrote: >> @@ -6657,7 +6646,19 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags) >> >> rcu_read_lock(); >> >> - sd = highest_flag_domain(cpu, sd_flag); >> + switch (wake_flags & (WF_TTWU | WF_FORK | WF_EXEC)) { >> + case WF_TTWU: >> + sd_flag = SD_BALANCE_WAKE; >> + sd = rcu_dereference(per_cpu(sd_balance_wake, cpu)); > > It's worth having a direct pointer for the fast path which we always > try to keep short but the other paths are already slow and will not > get any benefit of this per cpu pointer. > We should keep the loop for the slow paths > Which fast/slow paths are you referring to here? want_affine vs !want_affine? If so, do you then mean that we should do the switch case only when !want_affine, and otherwise look for the domain via the for_each_domain() loop? >> + break; >> + case WF_FORK: >> + sd_flag = SD_BALANCE_FORK; >> + sd = rcu_dereference(per_cpu(sd_balance_fork, cpu)); >> + break; >> + default: >> + sd_flag = SD_BALANCE_EXEC; >> + sd = rcu_dereference(per_cpu(sd_balance_exec, cpu)); >> + } >> >> /* >> * If !want_affine, we just look for the highest domain where