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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7B71CC388F9 for ; Thu, 19 Nov 2020 23:24:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33C762145D for ; Thu, 19 Nov 2020 23:24:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727047AbgKSXXy (ORCPT ); Thu, 19 Nov 2020 18:23:54 -0500 Received: from mx2.suse.de ([195.135.220.15]:52000 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726854AbgKSXXx (ORCPT ); Thu, 19 Nov 2020 18:23:53 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 55E37AC2E; Thu, 19 Nov 2020 23:23:51 +0000 (UTC) From: NeilBrown To: "tj@kernel.org" , Trond Myklebust Date: Fri, 20 Nov 2020 10:23:44 +1100 Cc: "jiangshanlai@gmail.com" , "mhocko@suse.com" , "peterz@infradead.org" , "juri.lelli@redhat.com" , "mingo@redhat.com" , "vincent.guittot@linaro.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH rfc] workqueue: honour cond_resched() more effectively. In-Reply-To: <20201109161007.GF7496@mtj.duckdns.org> References: <87v9efp7cs.fsf@notabene.neil.brown.name> <20201109080038.GY2594@hirez.programming.kicks-ass.net> <20201109140141.GE7496@mtj.duckdns.org> <20201109161007.GF7496@mtj.duckdns.org> Message-ID: <87ft55nd6n.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Mon, Nov 09 2020, tj@kernel.org wrote: > Given that nothing on > these types of workqueues can be latency sensitive This caught my eye and it seems worth drilling in to. There is no mention of "latency" in workqueue.rst or workqueue.h. But you seem to be saying there is an undocumented assumption that latency-sensitive work items much not be scheduled on CM-workqueues. Is that correct? NFS writes are latency sensitive to a degree as increased latency per request will hurt overall throughput. Does this mean that handling write-completion in a CM-wq is a poor choice? Would it be better to us WQ_HIGHPRI?? Is there any rule-of-thumb that can be used to determine when WQ_HIGHPRI is appropriate? Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJCBAEBCAAsFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAl+2/oAOHG5laWxiQHN1 c2UuZGUACgkQOeye3VZigbm8KxAAtKIpzJB8PC1aQMVBtitctNAScwsTSCh0ESxz JeN7Tv+t2lMnzq2doyWiQIZbEQv2l/t6J1TGXNHZm4NIscPO7MmfkoVQlobxmA9n sLS31PiFhje0IfqBHdNqSlP/GFH+zHA+ZLrIdpSbGFKWKJpyf+lksyUQ1Gidbonx 6tcdmKtM411PavZZaY7i8sZnuzTX8OSqBliMJtN8Zo8ebalUJIGr1oE4wuxa3pVU WUHGK4afhueqJ47UQ+4ELi8ubP8D9+ncl0DDOmGiqSfRPNRUQM27qn+JU8Ypv213 EoujmFtiDsP93F1UKyfEYexjobHxm7l4KoM6BJK77Qmqozlf6mEuuhlgZpZ28NP/ EtpSTR7byZzhZucpB62cYyFqTAlxGW+vL2NH3MRAiVzspPZitnzS5SxuMOPY3etg OwNHUKnrPP2sksQRxTG+TGrBUqJBVDJCfjW/n8w1847+bc8yq+8rM1fkHXFB5zR1 FbL10WY/tRHjpc/aSlP/XcaGbpA1K1C8x9Odqhiugm1SlVbgaMehix9FhAypkSt0 mPuaY4XiOE//rNKcSqijlpYm4M1DaRqHml8oX8z3xPKMub8xYGbQnC+oIFBS9nRQ 1iI2Qf834DSa8HvBPPaCMVShOWkVSIMbE63eCUdctDWjiWre/MexqjuzfprRouLP QDJ5OMc= =Jp9h -----END PGP SIGNATURE----- --=-=-=--