Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp572593imm; Fri, 22 Jun 2018 01:23:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI3aMNOcq+U2z1sKl5nIEc4C3kr4mwh2+SgPNV4prRz0PCpoI9nuciLP1KUTIKJ/xtmQvBb X-Received: by 2002:a62:ab0e:: with SMTP id p14-v6mr660960pff.211.1529655814738; Fri, 22 Jun 2018 01:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529655814; cv=none; d=google.com; s=arc-20160816; b=HTzcU6rdEez60BtH/5piiK8qe1IGDwz5zrykwf/UBlxWszfGal0ND9y5B7wyyXlDlo YbOZpAEurmfz23rB1RDBg9M4F4pM7A0c6CC3Pwyg+zH+FFcHuw0l5DjNsFCF08Fj9PNH cMOhPwkpeHA53Wv5J8pfR8gsxZzjzY927UNYdO8ZvFCiJ1VmBA3rePHLzzGnGlWsdRci Wcwa6I2g7sLALMS2wXOHiyP8aGLyedosUKtAaHBuN+Xdc4e1CC8otvSY+nvCsDBxJjjG vKQ1EhsBXdzZnDCDAeLpVxOURdziW/lII0Dk2gtfrOHjOAUm2H56mWvufLXSkrvsEKYm oFJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/ywQrtrOcK+zCC8fXurnnSh1McyWwq4NZ+ExoZ4J6DM=; b=akBnmLLE8dTz7yssTVYMJaOvHepjKORY60c/P7mZtvtXRl/yux0rKPcR92K05fR5sy XRrCtC7V1VognAWiOdyFaimwlEYA4JqBlu+Z+G34pe4GXecDi+jzyEUOW1WmQ+SWHL1E rvk5oeFM5UuPqIYWX79yPRWsB2QbsDCXbqLb8Fom/3Bw6Vs8tLQDDeDv3w/VxUs7nW1T 27TSJnDfOYOgaOtg77V5aO+oG3cDC4uChRs+YrKs3YiFvQJiR1l1L7KRklVrgDn5YWFf pvqjem0vfVhHpQbdgHSX98yOv8VBEIdsPv+CM4uJJW7lP0sV7LLhlhEP1L3l3Y8jHwtP 59hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r133-v6si660799pgr.17.2018.06.22.01.23.20; Fri, 22 Jun 2018 01:23:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751375AbeFVIW2 (ORCPT + 99 others); Fri, 22 Jun 2018 04:22:28 -0400 Received: from foss.arm.com ([217.140.101.70]:59608 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbeFVIW0 (ORCPT ); Fri, 22 Jun 2018 04:22:26 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E8E921435; Fri, 22 Jun 2018 01:22:25 -0700 (PDT) Received: from e108498-lin.cambridge.arm.com (e108498-lin.cambridge.arm.com [10.1.211.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 704AE3F58F; Fri, 22 Jun 2018 01:22:24 -0700 (PDT) Date: Fri, 22 Jun 2018 09:22:22 +0100 From: Quentin Perret To: Morten Rasmussen Cc: peterz@infradead.org, mingo@redhat.com, valentin.schneider@arm.com, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, gaku.inami.xh@renesas.com, linux-kernel@vger.kernel.org Subject: Re: [PATCHv3 1/9] sched: Add static_key for asymmetric cpu capacity optimizations Message-ID: <20180622082222.GD23168@e108498-lin.cambridge.arm.com> References: <1529485549-5191-1-git-send-email-morten.rasmussen@arm.com> <1529485549-5191-2-git-send-email-morten.rasmussen@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1529485549-5191-2-git-send-email-morten.rasmussen@arm.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Morten, On Wednesday 20 Jun 2018 at 10:05:41 (+0100), Morten Rasmussen wrote: > +static void update_asym_cpucapacity(int cpu) > +{ > + int enable = false; > + > + rcu_read_lock(); > + if (lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY)) > + enable = true; > + rcu_read_unlock(); > + > + if (enable) { > + /* This expects to be hotplug-safe */ > + static_branch_enable_cpuslocked(&sched_asym_cpucapacity); > + } > +} What would happen if you hotplugged an entire cluster ? You'd loose the SD_ASYM_CPUCAPACITY flag but keep the static key is that right ? Should we care ? And also, Peter mentioned an issue with the EAS patches with multiple root_domains. Does that apply here as well ? What if you had a configuration with big and little CPUs in different root_domains for ex? Should we disable the static key in the above cases ? Thanks, Quentin