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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 2D541C43461 for ; Wed, 9 Sep 2020 09:32:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8B7AF2087C for ; Wed, 9 Sep 2020 09:32:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zz5PF50M" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B7AF2087C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xcn1NLiJQSa4u9n6nlKK1TU6KGPHO2Yv6PoILfoC+XQ=; b=zz5PF50MoqcoClIcxaUgr9idD e3Rmhb5Cxd0SxcN2ut2GSPzOtVFgJmB+NIV2t+YADah+Tnl5HYv/FPIMhnmTeM4JXmPSwk9iRTnzP d2V9EIH4svEENPZkeQOvyBbFb0VoIOU95lTh32dQeXC37/KnF2DpYAzkw6o4S6oUk32sYpYvlTBDL YYimpzZEfdm+AWaVUkRG/HM+mPeTJy/fx2HuJlrdVaJ3Ma4Nhbv4BrghQGyLeO7M9Op9EuJf/Fy7N IGSo4qY7bPv1xrLsd1K/vqiczzlYpfI//ARm/K+Uh8J3VsbsjTe+jVXLYJSTD6GtHnFcDcKi3XbEU 00rWEIjfA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFwRk-0006M1-SX; Wed, 09 Sep 2020 09:31:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFwRg-0006Kp-Ut for linux-arm-kernel@lists.infradead.org; Wed, 09 Sep 2020 09:31:17 +0000 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 AD0491FB; Wed, 9 Sep 2020 02:31:15 -0700 (PDT) Received: from bogus (unknown [10.57.10.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1D07F3F66E; Wed, 9 Sep 2020 02:31:14 -0700 (PDT) Date: Wed, 9 Sep 2020 10:31:07 +0100 From: Sudeep Holla To: Jassi Brar Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU Message-ID: <20200909093107.GA10762@bogus> References: <20200605045645.GD12397@bogus> <20200605085830.GA32372@bogus> <20200610093334.yznxl2esv5ht27ns@vireshk-i7> <20200611100027.GB18781@bogus> <20200612052853.nds4iycie6ldjnnr@vireshk-i7> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200909_053117_103206_8B5CBD92 X-CRM114-Status: GOOD ( 33.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , Vincent Guittot , Arnd Bergmann , Devicetree List , Viresh Kumar , Linux Kernel Mailing List , Bjorn Andersson , Frank Rowand , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 08, 2020 at 10:23:33PM -0500, Jassi Brar wrote: > On Tue, Sep 8, 2020 at 4:15 AM Arnd Bergmann wrote: > > > > Picking up the old thread again after and getting pinged by multiple > > colleagues about it (thanks!) reading through the history. > > > > On Fri, Jun 12, 2020 at 7:29 AM Viresh Kumar wrote: > > > > > > On 11-06-20, 19:34, Jassi Brar wrote: > > > > In the first post in this thread, Viresh lamented that mailbox > > > > introduces "a few ms" delay in the scheduler path. > > > > Your own tests show that is certainly not the case -- average is the > > > > same as proposed virtual channels 50-100us, the best case is 3us vs > > > > 53us for virtual channels. > > > > > > Hmmm, I am not sure where is the confusion here Jassi. There are two > > > things which are very very different from each other. > > > > > > - Time taken by the mailbox framework (and remote for acknowledging > > > it) for completion of a single request, this can be 3us to 100s of > > > us. This is clear for everyone. THIS IS NOT THE PROBLEM. > > > > > > - Delay introduced by few of such requests on the last one, i.e. 5 > > > normal requests followed by an important one (like DVFS), the last > > > one needs to wait for the first 5 to finish first. THIS IS THE > > > PROBLEM. > > > > Earlier, Jassi also commented "Linux does not provide real-time > > guarantees", which to me is what actually causes the issue here: > > > > Linux having timeouts when communicating to the firmware means > > that it relies on the hardware and firmware having real-time behavior > > even when not providing real-time guarantees to its processes. > > > The timeout used in SCMI is simply based on how long the Juno (?) > platform takes to reply in most cases. Just FYI, the timeouts in SCMI can be platform specific. So each platform have flexibility to choose it's own choice of timeout and need not be stuck with so called *Juno values". The architects of SCMI believe the transfers(especially DVFS) must not exceed few 100s of uS and worst case for any transfers must be few ms. My initial choice of 30ms was based on the jiffes based timer and 100Hz. Architect claim that is too much, but I thought 3 jiffies at minimum in case we start timer when we are close to the boundaries. > Talking proper code-design, the timeout (if at all) shouldn't even be > a hardcoded value, but instead taken from the platform. > > > When comparing the two usage models, it's clear that the minimum > > latency for a message delivery is always at least the time time > > to process an interrupt, plus at least one expensive MMIO read > > and one less expensive posted MMIO write for an Ack. If we > > have a doorbell plus out-of-band message, we need an extra > > DMA barrier and a read from coherent memory, both of which can > > be noticeable. As soon as messages are queued in the current > > model, the maximum latency increases by a potentially unbounded > > number of round-trips, while in the doorbell model that problem > > does not exist, so I agree that we need to handle both modes > > in the kernel deal with all existing hardware as well as firmware > > that requires low-latency communication. > > > From the test case Sudeep last shared, the scmi usage on mhu doesn't > not even hit any bottleneck ... the test "failed" because of the too > small hardcoded timeout value. Otherwise the current code actually > shows better numbers. No disagreement on the latter part. But we can't ignore the bottlenecks even if they are rare. > We need some synthetic tests to bring the limitation to the surface. I > agree that there may be such a test case, however fictitious. For that > reason, I am ok with the doorbell mode. > Thanks ! -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel