Re: [PATCH 1/2] mailbox: switch to hrtimer for tx_complete polling

[Sudeep Holla]

On 24/07/15 06:02, Jassi Brar wrote:
> On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla <sudeep.holla@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/