From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FF2DC2B9F4 for ; Thu, 17 Jun 2021 07:52:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68D0E613CE for ; Thu, 17 Jun 2021 07:52:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230262AbhFQHyO (ORCPT ); Thu, 17 Jun 2021 03:54:14 -0400 Received: from foss.arm.com ([217.140.110.172]:49806 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229666AbhFQHyM (ORCPT ); Thu, 17 Jun 2021 03:54:12 -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 042F81042; Thu, 17 Jun 2021 00:52:05 -0700 (PDT) Received: from e123083-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B28F03F694; Thu, 17 Jun 2021 00:52:03 -0700 (PDT) Date: Thu, 17 Jun 2021 09:51:54 +0200 From: Morten Rasmussen To: Ley Foon Tan Cc: Dietmar Eggemann , Peter Zijlstra , Vincent Guittot , Ingo Molnar , Greg KH , linux-kernel@vger.kernel.org, Quentin Perret Subject: Re: sched: Question about big and little cores system with SMP and EAS Message-ID: <20210617074942.GA21285@e123083-lin> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 17, 2021 at 01:00:12PM +0800, Ley Foon Tan wrote: > On Wed, Jun 16, 2021 at 9:20 PM Dietmar Eggemann > wrote: > > > > - Quentin Perret > > + Quentin Perret > > > > On 16/06/2021 13:39, Peter Zijlstra wrote: > > > On Wed, Jun 16, 2021 at 07:29:26PM +0800, Ley Foon Tan wrote: > > >> Hi all > > >> > > >> Would like to ask the experts here regarding the Symmetric > > >> Multi-Processing mode (SMP) with Energy aware scheduler (EAS) support > > >> on the big + little cores system. > > > > > > And the you ask a question unrelated to either Symmetric MP or EAS :-) > > > > > >> Hardware system: > > >> Big and little cores have almost the same ISA, but the big core has > > >> some extension instructions that little core doesn't have. > > > > > > That problem is unrelated to big.Little / EAS, also by definition that > > > is not SMP seeing how the 'S' is a blatant lie. > > > > > > The simplest solution is to simply disallow usage of the extended ISA > > > and force mandate the common subset. The complicated answer is something > > > along the lines of: > > > > > > https://lkml.kernel.org/r/20210608180313.11502-1-will@kernel.org > > > > We don't encourage asymmetric ISA extensions for EAS*/CAS** on > > big.Little systems. > > It would be simply a nightmare to schedule tasks on such systems. > > > > The exception to this is the 'asymmetric 32-bit Soc' to support 32bit > > legacy Apps. The nightmare for scheduling is reduced in this case to CPU > > affinity, something the task scheduler has to live with already today. > > (+ DL admission control for 32bit tasks). > > > > * Documentation/scheduler/sched-energy.rst > > ** Documentation/scheduler/sched-capacity.rst > > Thanks for the reply. > Yes, forsee it is very complicated and nightmare for software to > support for SMP mode but HW is not real "symmetric". > That's why post the question here to ask the advice and comment from > experts here. So that can feedback to HW team. > Asymmetric extension instructions issue should more complicated than > asymmetric 32-bit app support, it can happen in all the areas (kernel, > app, library and etc). Indeed. Detecting what extensions a task might use difficult, if not impossible. Also, we certainly don't want to end up in situation where the CPU subsets supporting two extensions are disjoint and a task requires both extensions. Morten