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=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C51A9C04AB5 for ; Thu, 6 Jun 2019 08:45:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8874F207E0 for ; Thu, 6 Jun 2019 08:45:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="NGK9pbnW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727422AbfFFIpM (ORCPT ); Thu, 6 Jun 2019 04:45:12 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:45130 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbfFFIpL (ORCPT ); Thu, 6 Jun 2019 04:45:11 -0400 Received: by mail-lf1-f66.google.com with SMTP id u10so168865lfm.12 for ; Thu, 06 Jun 2019 01:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z3BynniL104up+cW9b6F68LH7Vk3TYOj+gBnu/PWYiY=; b=NGK9pbnWYhJ4n548kyDQ9PxhAo0Ex1P/YwAaGMfvoCN0RDA64no9A5UXi9Jmuc1K6z fuIZGvuAUEuYYqoFHHnc7r1K5kjLln83q5LvGPazaOvc+x+zScan/xXrkPe40uNBj77G T/CL77DCLUWBjtm8LTdxwwVQBSeUigdj+z0hhVbv11FJOJ/7LfzgRVWtfELzDTUjlDo0 8G+J1c3U9BQpMISDcsLfmKwdyr8Kxh16/bYqEgX5K5HHjWbqR2sFWcPdCY7l8R2hUkVa av6vEG6mG5CbVdoS8CPjekOUxg9nR2TtoX2IhIrJFB/qYWqrGInvdbo45Rw9aIqiijmA R+XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z3BynniL104up+cW9b6F68LH7Vk3TYOj+gBnu/PWYiY=; b=srMMU2LwT4nv6A7GpgclRVOi2owOTu3IU+8idiWvCOUXBw9Wp5SwIyIKN1oLhMhmQg 0JwBRLc0617oaJ+aBCgSmwDNPSh86Q0EJ2Zuz9du+gSztH8s/9T1pvrlwbUwbVG6gbJz FrBklPebvH+S4UhY6B7aL5kPkRMW7lQhyFzzOoZbtvPB7ii2U6kcHB2RDU4L0nh2mMeS TQjazeesOpGmdey+x3YPKFraaMU23jzujBV1UvDVMuAv8/x+aesXpL2Fo7/DkcR1/BjX IkFhMufdv4RLL6lo2ks1BqB/wRNtXsmqcaKfi3b7ltuszccVOpi9dMrpC2P7QtpomjSR dVPA== X-Gm-Message-State: APjAAAXOkMpd78IO/K/12UFsFH8L7vEg4U8yoVEpEJ/SQ4v4+YsVmRLF Tt7S1trHO5O/01hvcop9osMFHaWh63Elx9twHaUf0A== X-Google-Smtp-Source: APXvYqwinrI/Sz/MuhNNBaa8oDDl62sVOoVlxcqzhtV+9qT41TPe4niHspBpZO4IXiwufNQsJB/BdGZXP3nKEMufd+A= X-Received: by 2002:ac2:46d5:: with SMTP id p21mr20502406lfo.133.1559810709333; Thu, 06 Jun 2019 01:45:09 -0700 (PDT) MIME-Version: 1.0 References: <20190114184255.258318-1-mka@chromium.org> <155786856719.14659.2902538189660269078@swboyd.mtv.corp.google.com> <5cdf2dc8.1c69fb81.521c8.9339@mx.google.com> <20190605172048.ahzusevvdxrpnebk@queper01-ThinkPad-T460s> <20190606074921.43mbinemk3j565yu@queper01-ThinkPad-T460s> <9267b9ed-89b0-7b71-88a2-ca1894d4c497@arm.com> In-Reply-To: <9267b9ed-89b0-7b71-88a2-ca1894d4c497@arm.com> From: Vincent Guittot Date: Thu, 6 Jun 2019 10:44:58 +0200 Message-ID: Subject: Re: [PATCH] arm64: dts: sdm845: Add CPU topology To: Dietmar Eggemann Cc: Quentin Perret , Stephen Boyd , Amit Kucheria , Andy Gross , Matthias Kaehlcke , David Brown , Rob Herring , Mark Rutland , linux-arm-msm , "open list:ARM/QUALCOMM SUPPORT" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , Douglas Anderson , Rajendra Nayak , Morten Rasmussen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, 6 Jun 2019 at 10:34, Dietmar Eggemann wr= ote: > > On 6/6/19 10:20 AM, Vincent Guittot wrote: > > On Thu, 6 Jun 2019 at 09:49, Quentin Perret wr= ote: > >> > >> Hi Vincent, > >> > >> On Thursday 06 Jun 2019 at 09:05:16 (+0200), Vincent Guittot wrote: > >>> Hi Quentin, > >>> > >>> On Wed, 5 Jun 2019 at 19:21, Quentin Perret = wrote: > >>>> > >>>> On Friday 17 May 2019 at 14:55:19 (-0700), Stephen Boyd wrote: > >>>>> Quoting Amit Kucheria (2019-05-16 04:54:45) > >>>>>> (cc'ing Andy's correct email address) > >>>>>> > >>>>>> On Wed, May 15, 2019 at 2:46 AM Stephen Boyd = wrote: > >>>>>>> > >>>>>>> Quoting Amit Kucheria (2019-05-13 04:54:12) > >>>>>>>> On Mon, May 13, 2019 at 4:31 PM Amit Kucheria wrote: > >>>>>>>>> > >>>>>>>>> On Tue, Jan 15, 2019 at 12:13 AM Matthias Kaehlcke wrote: > >>>>>>>>>> > >>>>>>>>>> The 8 CPU cores of the SDM845 are organized in two clusters of= 4 big > >>>>>>>>>> ("gold") and 4 little ("silver") cores. Add a cpu-map node to = the DT > >>>>>>>>>> that describes this topology. > >>>>>>>>> > >>>>>>>>> This is partly true. There are two groups of gold and silver co= res, > >>>>>>>>> but AFAICT they are in a single cluster, not two separate ones.= SDM845 > >>>>>>>>> is one of the early examples of ARM's Dynamiq architecture. > >>>>>>>>> > >>>>>>>>>> Signed-off-by: Matthias Kaehlcke > >>>>>>>>> > >>>>>>>>> I noticed that this patch sneaked through for this merge window= but > >>>>>>>>> perhaps we can whip up a quick fix for -rc2? > >>>>>>>>> > >>>>>>>> > >>>>>>>> And please find attached a patch to fix this up. Andy, since thi= s > >>>>>>>> hasn't landed yet (can we still squash this into the original pa= tch?), > >>>>>>>> I couldn't add a Fixes tag. > >>>>>>>> > >>>>>>> > >>>>>>> I had the same concern. Thanks for catching this. I suspect this = must > >>>>>>> cause some problem for IPA given that it can't discern between th= e big > >>>>>>> and little "power clusters"? > >>>>>> > >>>>>> Both EAS and IPA, I believe. It influences the scheduler's view of= the > >>>>>> the topology. > >>>>> > >>>>> And EAS and IPA are OK with the real topology? I'm just curious if > >>>>> changing the topology to reflect reality will be a problem for thos= e > >>>>> two. > >>>> > >>>> FWIW, neither EAS nor IPA depends on this. Not the upstream version = of > >>>> EAS at least (which is used in recent Android kernels -- 4.19+). > >>>> > >>>> But doing this is still required for other things in the scheduler (= the > >>>> so-called 'capacity-awareness' code). So until we have a better > >>>> solution, this patch is doing the right thing. > >>> > >>> I'm not sure to catch what you mean ? > >>> Which so-called 'capacity-awareness' code are you speaking about ? an= d > >>> what is the problem ? > >> > >> I'm talking about the wake-up path. ATM select_idle_sibling() is total= ly > >> unaware of capacity differences. In its current form, this function > >> basically assumes that all CPUs in a given sd_llc have the same > >> capacity, which would be wrong if we had a single MC level for SDM845. > >> So, until select_idle_sibling() is 'fixed' to be capacity-aware, we ne= ed > >> two levels of sd for asymetric systems (including DynamIQ) so the > >> wake_cap() story actually works. > >> > >> I hope that clarifies it :) > > > > hmm... does this justifies this wrong topology ? > > select_idle_sibling() is called only when system is overloaded and > > scheduler disables the EAS path > > In this case, the scheduler looks either for an idle cpu or for evenly > > spreading the loads > > This is maybe not always optimal and should probably be fixed but > > doesn't justifies a wrong topology description IMHO > > The big/Little cluster detection in wake_cap() doesn't work anymore with > DynamIQ w/o Phanton (DIE) domain. So the decision of going sis() or slow > path is IMHO broken. That's probably not the right thread to discuss this further but i'm not sure to understand why wake_cap() doesn't work as it compares the capacity_orig of local cpu and prev cpu which are the same whatever the sche domain=C5=93 > But I support the idea of not introducing Phantom Domains in device tree > and fix wake_cap() instead.