From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754051AbbGXIr5 (ORCPT ); Fri, 24 Jul 2015 04:47:57 -0400 Received: from foss.arm.com ([217.140.101.70]:43369 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752401AbbGXIrx (ORCPT ); Fri, 24 Jul 2015 04:47:53 -0400 Message-ID: <55B1FBB6.9010803@arm.com> Date: Fri, 24 Jul 2015 09:47:50 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jassi Brar CC: Sudeep Holla , Linux Kernel Mailing List , Juri Lelli Subject: Re: [PATCH 1/2] mailbox: switch to hrtimer for tx_complete polling References: <1437568131-6398-1-git-send-email-sudeep.holla@arm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/07/15 06:02, Jassi Brar wrote: > On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla wrote: > >> we might end-up waiting >> for atleast a jiffy even though the response for that message from the >> remote is received via interrupt and processed in relatively smaller >> time granularity. >> > That is wrong. > No see below. > If the controller supports TX interrupt it should set txdone_irq, > which prevents polling i.e, controller driver calls mbox_chan_txdone. > > If the controller doesn't support TX interrupt but the client > receives some ack packet, then the client should set knows_txdone and > call mbox_client_txdone. Again you don't have to wait on polling. > Sorry if I was not clear in the commit message, but I thought I did mention TXDONE_BY_POLL. The case I am referring is definitely not TXDONE_BY_IRQ or TXDONE_BY_ACK. > If there's neither TX interrupt nor some ack packet, only then it has > to rely on polling. In which case, I doubt if we can desire some > functionality that requires sub-jiffy notification of TX_done. > Can you elaborate on why do you think we can't desire some functionality that requires sub-jiffy notification of TX_done ? Few reasons I have in mind as why we need that: 1. The remote processor is capable of dealing with requests in orders of milliseconds. E.g. on Juno it reports the DVFS transition latency is 1.2ms. Now if we report that to CPUFreq governor, we need to ensure that. With current jiffy based timer we see latencies > 10ms. 2. Because of that, under stress testing with multiple clients active at a time, I am seeing the mailbox buffer overflows quite easily just because it's blocked on Tx polling(almost 10x slower) and doesn't process new requests though the remote can handle. 3. Also there are efforts for scheduler-driven cpu frequency selection where the desired latency should be as low as possible. Juri(cc-ed) is working on that and reported this issue with mailbox core. Hope this clarifies the reasons for switching to hrtimer. Regards, Sudeep