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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 02403C4363A for ; Tue, 27 Oct 2020 21:12:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A36B220738 for ; Tue, 27 Oct 2020 21:12:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D6Wr3oaM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1832137AbgJ0VMH (ORCPT ); Tue, 27 Oct 2020 17:12:07 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:41178 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2501973AbgJ0VMG (ORCPT ); Tue, 27 Oct 2020 17:12:06 -0400 Received: by mail-lj1-f193.google.com with SMTP id p15so3391112ljj.8; Tue, 27 Oct 2020 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xx452EybhZY/Be3m6ZPFyPAZdRMh+EqfNW2ocWqJUkQ=; b=D6Wr3oaM9cb6BAmiXy3RkDD4ypsh2yfV8mv0vEtF5pP1za3dGFHgk3xtjw87AkfiqN omzwflvsg5c3541QMlIKkoHT4+D1FIZ2bFGO7nnh7r16tMFPnPouySY0KiZ5B+0yFUzW jAwlJz05zfj7nRFVKSs2LqKL7Xkxs0q+w55fq+OEbWp6C83f1YUR5Z4sd8rvoQQiatgt sRSC/upzBI+sqHvANT1BPo8HtPkXVjBRc9jwm4rpY3tOGQdLsf0lLSaQL1PLASU1v8qu hGfPJkzaUUUVklWeOsK5NV5iT6rRLnCqvMy6tGpA+sbqkn6kkN5iOmAaLWkzt5cdR3/q /WpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xx452EybhZY/Be3m6ZPFyPAZdRMh+EqfNW2ocWqJUkQ=; b=PtAJfyoJHnWE2jZgaC9V9pbcKZMKpbfXSMGq5/mTUisH5l2m9zPGTtPo0f23LR/rTo /k++nAyjR5HSFfqcKtjuWyyc3g9RSL8KGfIwwjWExm+DboEu0UiFfuUmeqEaSw3UrZVc T9EaMIYH742dKJ3B7Ii0AUqUa2c9hab5DxIG3GiadMiltjQkgOT2uuFVJ2vR/ousl3qO D+hRy0mviLpB2Kj013JriS4FrbwwZljySZpRPp7lWz/i3ees1HeiHeGqXYU8PzvZVH1S Ad5XwGeq3fVY1Nli8no5Fw3sWvHRNbav36sW8lCt88sUS02ZVNkRmBurM4+DTVq+PfMZ gCCw== X-Gm-Message-State: AOAM5320kx+BqcBWRUILprcglmsjYW+6ewipODSgDJPCEsoKsAtW+xKO ooRw6xWLs4HhWE/PdegV2nPEG1F/ZGs= X-Google-Smtp-Source: ABdhPJwv14XNGp2zM2xoLnCiq9kknsnE1yraNpyVdtEy7elcpP9cB4Kgv07q0csNDEYeh5IGZ093Gg== X-Received: by 2002:a05:651c:1291:: with SMTP id 17mr1768187ljc.52.1603833122475; Tue, 27 Oct 2020 14:12:02 -0700 (PDT) Received: from [192.168.2.145] (109-252-193-186.dynamic.spd-mgts.ru. [109.252.193.186]) by smtp.googlemail.com with ESMTPSA id i139sm292785lfi.276.2020.10.27.14.12.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 14:12:01 -0700 (PDT) Subject: Re: [PATCH v6 33/52] memory: tegra20: Support interconnect framework From: Dmitry Osipenko To: Thierry Reding Cc: Jonathan Hunter , Georgi Djakov , Rob Herring , Michael Turquette , Stephen Boyd , Peter De Schrijver , MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Mikko Perttunen , Viresh Kumar , Peter Geis , Nicolas Chauvet , Krzysztof Kozlowski , linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org References: <20201025221735.3062-1-digetx@gmail.com> <20201025221735.3062-34-digetx@gmail.com> <20201027141152.GN1822510@ulmo> <713bf4eb-dc5b-9c4b-4ab4-23b36ba4fab1@gmail.com> Message-ID: <4ff5d718-5e05-fc11-9795-7c3fef4525d3@gmail.com> Date: Wed, 28 Oct 2020 00:12:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <713bf4eb-dc5b-9c4b-4ab4-23b36ba4fab1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 27.10.2020 23:22, Dmitry Osipenko пишет: ... >>> + >>> + *agg_avg += avg_bw; >>> + *agg_peak = max(*agg_peak, peak_bw); >> >> I'm not very familiar with ICC, but shouldn't the aggregated peak value >> be the sum of the current aggregated peak and the new peak bandwidth? >> Currently you're selecting the maximum peak bandwidth across all >> clients, so isn't that going to be too small if for whatever reason >> multiple clients need peak bandwidth at the same time? The current variant with max-peak selection should be okay since it takes into account the competing ISO bandwidths of other devices by overestimating the bandwidth. For now we have only display ISO clients and it won't be a problem to tune the algorithm later on if it won't work well for other ISO clients.