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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 BCBF6C76186 for ; Mon, 29 Jul 2019 20:12:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D86F205F4 for ; Mon, 29 Jul 2019 20:12:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tGszBRzP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730159AbfG2UMu (ORCPT ); Mon, 29 Jul 2019 16:12:50 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:42984 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728931AbfG2UMq (ORCPT ); Mon, 29 Jul 2019 16:12:46 -0400 Received: by mail-ot1-f66.google.com with SMTP id l15so63866497otn.9 for ; Mon, 29 Jul 2019 13:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLtTrMx9bNgV2e5WT+U4GbHrtwL6tZTxsShVYrHD6s8=; b=tGszBRzPbi6dD+NRM2bN3t9p9ftDIDFlandOwt8DpUAVkYZ4vU9DgEhnuPtU35uxQ/ KJflcPgXXlm6X0pPEHjnN6jl2/WiXLYOc8kTsFgZjm52JZb//9cc8NSlJ0h/z9Gntkww IHh1MZfFJO8t/jlHNiHPzn2KUh++WFzQaiWc7R7+sEi8mVNA/wgN1EoPKSVvlaWeX9U4 Cqmw8jl8KuzAg9Pto9YHhmzF1ClROkAaxGZTDhB2AgrMQ6fC9wMp2k2yFzK7yUsFbviP jHFwQ0oNY3I0nJ4xOe0eVdhRJm6bn2zkQQhWvisj0JWCFFjM/ME1xtG/G/UGYMcwvYHp hFtw== 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; bh=rLtTrMx9bNgV2e5WT+U4GbHrtwL6tZTxsShVYrHD6s8=; b=qCkOBR3RFHLitHMBMnrkw7bXRXnNS1SpI4byqxHOEbANkK50vqarVxtR8IKa+DzRVJ 9Job05jkQITLh10Cc9GZRYEyQcaN/ssHFvD6tNQW+DooYXJzndMon779xeG1TpsmJAWH WaKFh9E9sMyINbFAfBIMIJb2MRWi+ehRqgWbzNAh3sdwWquVCcFnvixE7Nw6TrrwPYYN QkfsxljB+5Kp6eFoqerXw6emnDID72A4Qn7RIGpdXNToraB7QiPKUI7qTw6ZETsulrme qXB7yjm14993REyvD4BUstL6UWwGHQYORSb0OEFyWriI46jmqirC25OD4Br8hs89HdIz bSvQ== X-Gm-Message-State: APjAAAVPivrS3UMxuoWCmPY6dNnJwUS8zOKgI09owGmWB/+uFqRLJR8F MwzFUy/wi6EXQdbE2UJ9zLEsYyaby54hciXjlFTuDA== X-Google-Smtp-Source: APXvYqyalfL7uKo9yflW1Pyt9NtQK1vzEzGUhuLM63HRXQD3JmtpxZUwdeQTJ4TkIvAAhjMpgK7mWf7IUvOUuGB9nzw= X-Received: by 2002:a9d:6256:: with SMTP id i22mr4789080otk.139.1564431164859; Mon, 29 Jul 2019 13:12:44 -0700 (PDT) MIME-Version: 1.0 References: <20190703011020.151615-1-saravanak@google.com> <20190717103220.f7cys267hq23fbsb@vireshk-i7> <20190718053746.64drmonk72vwnt4s@vireshk-i7> <20190729092454.6lfqzmhkvrhpimsp@vireshk-i7> In-Reply-To: <20190729092454.6lfqzmhkvrhpimsp@vireshk-i7> From: Saravana Kannan Date: Mon, 29 Jul 2019 13:12:08 -0700 Message-ID: Subject: Re: [PATCH v3 0/6] Introduce Bandwidth OPPs for interconnect paths To: Viresh Kumar Cc: Georgi Djakov , Rob Herring , Mark Rutland , Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , Vincent Guittot , "Sweeney, Sean" , David Dai , Rajendra Nayak , Sibi Sankar , Bjorn Andersson , Evan Green , Android Kernel Team , Linux PM , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Mon, Jul 29, 2019 at 2:24 AM Viresh Kumar wrote: > > On 18-07-19, 21:12, Saravana Kannan wrote: > > On Wed, Jul 17, 2019 at 10:37 PM Viresh Kumar wrote: > > > I would like > > > to put this data in the GPU OPP table only. What about putting a > > > range in the GPU OPP table for the Bandwidth if it can change so much > > > for the same frequency. > > > > I don't think the range is going to work. > > Any specific reason for that ? The next sentence was literally explaining this :) Fine to debate that, but ignoring that and asking this question is kinda funny. > > If a GPU is doing purely > > computational work, it's not unreasonable for it to vote for the > > lowest bandwidth for any GPU frequency. > > I think that is fine, but if the GPU is able to find how much > bandwidth it needs why can't it just pass that value without needing > to have another OPP table for the path ? You were asking this question in the context of "can the GPU OPP just list all the range of bandwidth it might use per GPU frequency". My point is that the range would be useless because it would the entire available bandwidth range (because purely compute work might not need any bandwidth). Whereas, what the GPU's algorithm actually needs might be the list of "useful" bandwidth levels to use. Also, as we add more ICC request properties, this range idea will not scale. -Saravana