linux-kernel - Re: [PATCH 1/2] mailbox: switch to hrtimer for tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Jul 2015 09:47:50 +0100
From:	Sudeep Holla <sudeep.holla@....com>
To:	Jassi Brar <jassisinghbrar@...il.com>
CC:	Sudeep Holla <sudeep.holla@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Juri Lelli <Juri.Lelli@....com>
Subject: Re: [PATCH 1/2] mailbox: switch to hrtimer for tx_complete polling



On 24/07/15 06:02, Jassi Brar wrote:
> On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla <sudeep.holla@....com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/