Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1699896ybz; Thu, 16 Apr 2020 13:59:27 -0700 (PDT) X-Google-Smtp-Source: APiQypIOgIjmdBdrn6LC9oNbLqF/gMVTGnsiODxtr1lJQt+yNHDAuRhmHNQMHPb3RvBqFel/sJhD X-Received: by 2002:a50:b062:: with SMTP id i89mr119827edd.72.1587070767517; Thu, 16 Apr 2020 13:59:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587070767; cv=none; d=google.com; s=arc-20160816; b=tQkQQLEODLw15Q4IUGJy5geeOj6CYWq58ZvbNBtl4zWr7wZiaqyrldJm/c7l0fYHsl SHGTODjH9sGo/uK69Y6RD5d/9eV0F/xz8epo+OnnKiA6DCiwk+ZroT2gWHt4S9B+lluY 8PtIGO4tR2iokCRUVTZirtI3GHA2Z4+Cpg3yN0zU6FuXkrih/FvNIL8FTMAV/heQ4Ecm ieAeP3GwHwjsR3qhcZ2Z2giGtu5imbKoqNrI7Y4cgWSJALFD4KID2d8295OFnK983TGN 4JA+A7dKsy/KzaDx9uTEBKUBh3rTFqB3LqlqcsTb20kzeEvgm+W1m5lPDkSiS0a9pS/y bLCA== 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=L9rygbwqXpekELP35qhPLBqsoooW4boHKhFaB7+h5A8=; b=AbmIbG6zWOmiwinmkXZnpl8dBItgvfHZ9ckIyk78rfFnQz7TVbQSQnblI+9mDKTp1k fL7qEtfkw5RTn7JScQbF2hXq6rOVfjFwzOjkEHyZeqePBMhs+2GOjxAtWaZN5Z56tJr3 qHc16fM+2tB1J1/rh5aotu2aNqtL/qrABbDxwt1r3oez5ONdwzjGTqJGrcU+5Ge9S/3O osmKSkDvwGAXsiRz156TX/0Ae/JdkyZ8HeKBX4SElwH5jwq7CLPyrmlHMenspyxiXM0f INRaDGom5O8BUkuH9+6OzYYqezpOE4nx5ATk+150ZskYnD7JRfTL6s+9b+dz8A659jZC T5Xw== 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 l9si12822592ejh.463.2020.04.16.13.59.04; Thu, 16 Apr 2020 13:59: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 S1728549AbgDPUy7 (ORCPT + 99 others); Thu, 16 Apr 2020 16:54:59 -0400 Received: from foss.arm.com ([217.140.110.172]:41368 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbgDPUy6 (ORCPT ); Thu, 16 Apr 2020 16:54:58 -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 16C7F30E; Thu, 16 Apr 2020 13:54:58 -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 4B9BE3F237; Thu, 16 Apr 2020 13:54:57 -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: Dietmar Eggemann , linux-kernel , Ingo Molnar , Peter Zijlstra 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 21:54:52 +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 16:58, Vincent Guittot wrote: >> --- >> if (wake_flags & WF_TTWU) { >> if (want_affine) { >> // We can cache that at topology buildup >> sd = highest_flag_domain(cpu, SD_WAKE_AFFINE); >> >> if (cpumask_test_cpu(prev_cpu, sched_domain_span(sd) && >> cpu != prev_cpu) >> new_cpu = wake_affine(); >> >> } >> // Directly go to select_idle_sibling() >> goto sis; >> } >> >> // !want_affine logic here >> --- >> >> This in turns mean we could get rid of SD_BALANCE_WAKE entirely... I'm a >> bit more reluctant to that only because the last SD_BALANCE_WAKE setter was > > For now, we should probably skip the additional test above: "if > (wake_flags & WF_TTWU) {" and keep SD_BALANCE_WAKE so we will continue > to loop in case of !want_affine. > > We can imagine that we might want at the end to be a bit more smart > for SD_BALANCE_WAKE and the slow path... like with the latency nice > proposal and latency-nice=19 as a example > Good point. I'll go for the first option and see where I end up; I'd like to cache the other domain pointers if possible, I'll do some benchmarking and see if I can do that without another switch case. >> removed fairly recently, see >> a526d466798d ("sched/topology: Remove SD_BALANCE_WAKE on asymmetric capacity systems")