Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Arend van Spriel <aspriel@gmail.com>
To:     Tejun Heo <tj@kernel.org>, Sean Anderson <sean.anderson@seco.com>
CC:     <linux-wireless@vger.kernel.org>,
        Kalle Valo <kvalo@codeaurora.org>,
        "Chi-hsien Lin" <chi-hsien.lin@cypress.com>,
        Franky Lin <franky.lin@broadcom.com>,
        <SHA-cyfmac-dev-list@infineon.com>,
        Hante Meuleman <hante.meuleman@broadcom.com>,
        Wright Feng <wright.feng@cypress.com>,
        Arend Van Spriel <arend.vanspriel@broadcom.com>,
        <brcm80211-dev-list.pdl@broadcom.com>
Date:   Tue, 17 Aug 2021 23:14:38 +0200
Message-ID: <17b55f75630.279b.9696ff82abe5fb6502268bdc3b0467d4@gmail.com>
In-Reply-To: <YRv/xUlC5sIMbCxI@slm.duckdns.org>
References: <20210802170904.3116223-1-sean.anderson@seco.com>
 <e6eb89af-b81e-b96e-70a6-c9498eb681fd@seco.com>
 <17b551dc6e0.279b.9696ff82abe5fb6502268bdc3b0467d4@gmail.com>
 <c5bba530-1002-a3fa-322a-1045bf7ee4c2@seco.com>
 <YRv/xUlC5sIMbCxI@slm.duckdns.org>
User-Agent: AquaMail/1.30.1-1828 (build: 103001000)
Subject: Re: [PATCH] brcmfmac: Set SDIO workqueue as WQ_HIGHPRI
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On August 17, 2021 8:28:23 PM Tejun Heo <tj@kernel.org> wrote:

> Hello,
>
> On Tue, Aug 17, 2021 at 02:21:55PM -0400, Sean Anderson wrote:
>>> While I understand the obvious gain it seems like a wrong move to me. What 
>>> if all workqueues in the kernel would start using this flag? I bet the gain 
>>> above would be negated and all are equal in the eyes of .. the kernel
>>
>> Is there an official policy on what counts as high-priority? Using some
>> very-scientific methodology [1], it seems like most high-priority
>> workqueues are in drivers/net and fs. Making these queues high-priority
>> seems to be commonplace. For example, in fe101716c7c9 ("rtw88: replace
>> tx tasklet with work queue"), Po-Hao Huang remarks:
>
> I think this is actually a good candidate for HIGHPRI. As you noted, stuff
> which interacts with hardware in latency sensitive manner with impact on
> observable performance is one of the common use cases. The alternatives
> would be doing it from hard/softirqs which are higher priorities anyway.

Hi, Tejun

Thanks for the explanation.

Regards,
Arend