Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1621130ybt; Thu, 2 Jul 2020 09:38:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzToWFgUnNKRcUNJXY0ku75W8J+OtTtaF08U7sJ9wKMDui3Gi9xx8a8Ieb2twE3xxGnpJWb X-Received: by 2002:a17:906:1f0d:: with SMTP id w13mr29616931ejj.0.1593707917846; Thu, 02 Jul 2020 09:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593707917; cv=none; d=google.com; s=arc-20160816; b=EHNiv5t/J7HsY8DClEjRxgJMhmSShNt9vS1JcQCaXYP0xvX/sTdNu2cdyscuFGrSOU XGForyqSSfDEDTa60TfLnmYPYp97JTlgf+g1ZjJjNtcFYRIB9CoO1b0s7OQX/7E6cruO sFG5eQNHn+2XMeS6LU6RTRViDJyQyfk/G1BdzmWB2VDQ6SSr9Uu7l54fLo+S936v1/k8 gyNFzhQfAnFjUgJuW77R3WKKvbb//XD2lOc9irkfHdGS3lAfELMk5TXt/3WBERsjhmCp RGKE6AiORuM/RSU8OmvAYpFMRld6Ny2T6S4CPAUmaIhTg+u4/bs490iOwR08TW2LgdbW 838Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=fnuWmlXLjirzYouN6+gZo7kUrpDYboNODzPAe5CcqpQ=; b=WEWy0zdM9hT8kj0PwAjxXXYsNFEMSbUJmX0o8s+cNRYdMn09zf82r1vsT5SX7BFebE jxlzpORzr606miXAuFjRRuiCdaRlpwQpcip7eanrNJW9owslpQH77e4x7btsuJiQoZXQ up7FCdDYLJJ53O6us9j9uHk6s0tSeV4E8UOHKuSvXWJcvhlJvNFpJs22BZSbfF26JY1q 8FVE1A8/2bbu4oubA+8FSzbG2PTWqmLbPPzCBvgIGH1gCduuJxuOq0szpB2TxQEaVySS BfQlig42C+EUuacM8S5O2ekkUwnCZ5IMdaKvi6e6rzd1flKz843U2FD4fPyybrNG0vqA zlJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ve3ytCGD; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w5si5984281ejb.404.2020.07.02.09.38.14; Thu, 02 Jul 2020 09:38:37 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=ve3ytCGD; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726934AbgGBQh4 (ORCPT + 99 others); Thu, 2 Jul 2020 12:37:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726912AbgGBQhx (ORCPT ); Thu, 2 Jul 2020 12:37:53 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C982C08C5C1 for ; Thu, 2 Jul 2020 09:37:53 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id g75so27701827wme.5 for ; Thu, 02 Jul 2020 09:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fnuWmlXLjirzYouN6+gZo7kUrpDYboNODzPAe5CcqpQ=; b=ve3ytCGDue3yKA4w4IeO9pBH60YZ2lezY/MIWMAeI8GC8DhvGZtRWivTpbJbJ+tXjZ APwXScg0Ro0qDkuU5u24m1rYjO3lPuAe4YaLbhPgr1EIbSXhfq7llLvYRx6rRuym2R6o grxmhiP8D4WVq1zXmYH8yCV+CYFxzVVxhEWf41cduprGGFqY5+K+BuHpVgTxbPLj8inb tIYQIDP/6ovb8uLn3ysDaSemvtMxKK1JAIaz3/Abe5oxhgcVcd9mqzOGi3uNZRm3mhzJ md+hEZAcI7iCGRl6yzsX/x37D+qVz9LsystgrRp03g1h8JRK/6jzIAdot5t3WEcNORsZ r7Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fnuWmlXLjirzYouN6+gZo7kUrpDYboNODzPAe5CcqpQ=; b=P8hvFHef/+0ozg3FZ65kkK8hWMQj6lMJSYTKNz6QTMfbfkUi/bZadRjyDgBEPCSw3n NUKBx9TeSJX1scGW9UpE7/H4yk1P6j7RHe4lwnKRh+7lEcSokh/MlfXtNJtjDyVeTXKw 7yJUEEUQ5OfpeWsKlVbwvh4y4vF5AvHmIJ6avC+sRwak40Lgculq++h4HaeYsO1J6DmZ 1otiGazCGBgJb7EbDvg+SSScuVR6koH/GRlE2FCCc1t3wldr4TXD+Yr0CttZc0M8HBvW 0kHAegi2JeL5ByBaQgruCLW7Fqhx8a6rnor8F63JAACYP98WOcY0Ex80IslOKdi9oHER pFPQ== X-Gm-Message-State: AOAM530OLFtUH6M6rEt1LtaWV2LZBI8yRIwNOyaFOAnECRjSym49abKI Hf1gWz0A8xgXBs14OttRwB32RA== X-Received: by 2002:a7b:c38c:: with SMTP id s12mr32283269wmj.136.1593707871931; Thu, 02 Jul 2020 09:37:51 -0700 (PDT) Received: from google.com ([2a00:79e0:d:110:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id z8sm8954938wmg.39.2020.07.02.09.37.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2020 09:37:51 -0700 (PDT) Date: Thu, 2 Jul 2020 17:37:48 +0100 From: Quentin Perret To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, morten.rasmussen@arm.com Subject: Re: [PATCH v3 2/7] sched/topology: Define and assign sched_domain flag metadata Message-ID: <20200702163748.GA1125675@google.com> References: <20200701190656.10126-1-valentin.schneider@arm.com> <20200701190656.10126-3-valentin.schneider@arm.com> <20200702121536.GA765585@google.com> <20200702154514.GA1072702@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 02 Jul 2020 at 17:25:41 (+0100), Valentin Schneider wrote: > It's actually pretty close to what happens with the LLC domain on SMP - > select_idle_sibling() doesn't look outside of it. The wake_affine() stuff > might steer the task towards a different LLC, but that's about it for > wakeups. We rely on load balancing (fork/exec, newidle, nohz and periodic) > to spread this further - and we would here too. Sure, but on SMP the search space in select_idle_sibling is always consistent -- you search within the LLC. With the fix you suggested, CPUs 0-3 will search within their LLCs, while CPU4 searches the entire system, which creates an imbalanced mess IMO. For affine wake-ups, you could migrate from CPU4 -> CPU0-3, but CPU0-3 to CPU4 is not possible, so this asymmetry is almost guaranteed to actively create imbalance. And sure, the periodic load balancer ought to fix it, but really wake-up balance and periodic load balance should be pushing in the same direction and not fighting against each other. Anyways, enough bikeshedding for today, I'll try and have look at the rest of the series :) Cheers, Quentin