Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1261930ybz; Thu, 16 Apr 2020 06:07:14 -0700 (PDT) X-Google-Smtp-Source: APiQypIXqxP3ftac6vMr+LYsumM4kyXEQKP2bI5RchXJtCGVolyp7RpsjO2H/FU+bCssqzlkf/Qt X-Received: by 2002:a17:906:4351:: with SMTP id z17mr9787380ejm.346.1587042434022; Thu, 16 Apr 2020 06:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587042433; cv=none; d=google.com; s=arc-20160816; b=fMl0+LxVuy98wzw/gYz8SeGc9tRbbHH5SGD3wScwo5nT9Uo3X0kJkFNwCQsKb4ctaN 5nk4M/8Dstb96DGqR++/ti6ADd+kczzFN/p6XpX7E5/E7ra7T5UjkTajxKv5/y9BE8Sf NXWhvBmsrtqapRJJ04OZYLOwUlrpwM0PT/zDT90dmqPzh67arQdUjP1J3fhGzU/W053o Pf5tEoErgua8tTQteQoT4Sh1ZuqDCgzbC38JSA4C3eAq6mIUiurm+CYoJw+Awa3Nbf1/ xq4RSdAJ15IPmGpwVfYnLuL6iEvlRexC4rkLgXBQJC7ardtsAO3wSmpH/kiDepoSJ1eq M/wg== 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=t3oaRFW4uFS+WL+ENJsGdkLijsSF0Z9OD0+qAcfQM4c=; b=PoCDWpJb3gYVcB22ty9ixjj3sxVUTM5S1zHxiErH62HhxSQ/qDxRWfPWI6pBy3gio9 2c76zxKfS1aBr80BhHLcGWTCkdiCojxdw2TqoVDzX61ROLrhJNA9qXnFiRVdqa4jD9It IaI473gHqq1JpX4WkERRuKzr5wG+96jdyWWezUJ0NTe401xkHdHonOWLM0kyskB81f8a jdM16k02VK7P3y2xABw4Ue/jxnmgI9086dD5piHEyqlzXX75zND5BVb2Bsz6XouUNjKm AA2mMaDf7DQcdKPS+2R81MB7fNtMW7HkjcgUZTtNHZPKc6k73bKcGEDx34/aVGo8tUT5 Itrw== 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 a31si5390139ede.290.2020.04.16.06.06.49; Thu, 16 Apr 2020 06:07:13 -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 S2894835AbgDPNE2 (ORCPT + 99 others); Thu, 16 Apr 2020 09:04:28 -0400 Received: from foss.arm.com ([217.140.110.172]:60510 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2894786AbgDPNEZ (ORCPT ); Thu, 16 Apr 2020 09:04:25 -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 A79F61FB; Thu, 16 Apr 2020 06:04:24 -0700 (PDT) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8EB53F68F; Thu, 16 Apr 2020 06:04:23 -0700 (PDT) Subject: Re: [PATCH v3 9/9] sched/topology: Define and use shortcut pointers for wakeup sd_flag scan To: Valentin Schneider , Vincent Guittot Cc: linux-kernel , Ingo Molnar , Peter Zijlstra References: <20200415210512.805-1-valentin.schneider@arm.com> <20200415210512.805-10-valentin.schneider@arm.com> From: Dietmar Eggemann Message-ID: Date: Thu, 16 Apr 2020 15:04:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: 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 16.04.20 12:24, Valentin Schneider wrote: > > 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? Coming back to the v2 discussion on this patch https://lore.kernel.org/r/20200311181601.18314-10-valentin.schneider@arm.com SD_BALANCE_WAKE is not used in mainline anymore, so wakeups are always fast today. I.e. you wouldn't need a per_cpu(sd_balance_wake, cpu) since it's always NULL. I.e. want_affine logic and the 'for_each_domain(cpu, tmp)' isn't needed anymore. This will dramatically simplify the code in select_task_rq_fair(). But I guess Vincent wants to keep the functionality so we're able to enable SD_BALANCE_WAKE on certain sd's?