Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp840396pxb; Thu, 19 Nov 2020 15:26:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJyaQrrrcXkO9BhfzDQajvhlzCB+DnOPDLxhGJAsTyXNljg1LR4+lHrCUMhcWEl8sS4RcGIc X-Received: by 2002:a17:906:2452:: with SMTP id a18mr2841014ejb.66.1605828388492; Thu, 19 Nov 2020 15:26:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605828388; cv=none; d=google.com; s=arc-20160816; b=rVpiBMXrp4xOC4+CQOjxxCUvsBdTXwtrZH3yVU1/xBK5u6z1HcvNvV4eeGMwkYV8Nh lLtMpqgNuJMoYBz/wjIC2MhcwLDkcwGYfTpezGhNSAVE6om1qx+cL08VseKHHpR0jjqZ tsa4U2ESVncXaNi4MyddFa0GK3qWeXDrjQSo+WVKzsXgtP2v1xnd3nCVUt04DDk0Bk6V oHgeKrGrkiRMn6L3uLZZaGDaRcPxuwf6o0n2DaeTO4JQXQCPMEDI8731BDZJRQ6LTBEl LmVmdCR7W88zEsl1/lu1ckUnE/oJmbCaPiNOlZt9fJ0hMFk0W3EGMudzaUyzdN9dbK92 Yv3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:references:in-reply-to :subject:cc:date:to:from; bh=mnbCmHj9LxMkHnC+kK/9nOPLlDYlbri5C9u73C5GsFw=; b=MuXjqiEMo7VsCfvFt54nXuQFg1Th4YvkHxkouQw+bCxLObTf5vB5HJQep1fDauHm0U CIpHE3n9GFa4bSAwTats2AIC1Xe4tw9OHnRiup3LdiX9+UxscZhvvj0JgPCdwZEHlMd5 F0386o0FkIkJ+b2U7/w8cy2h8R4a+KMZE8vHM18BtPtt4BERnFJXOjm5y5H1bV5YOW9V gmwTdmy09KCYgunTZkv6I7CruF6sJZhHOyH/guqDotwUrjlWSGa82EIU+1YCjjbwSNLS 8mls4h4tgNQCW3VieCjmEr6dAIJEgLcmpOkt8zIluxgjuV1JBJ81Lc7JsCOP5cyUAP9E rnpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i23si750432edg.60.2020.11.19.15.26.02; Thu, 19 Nov 2020 15:26:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727042AbgKSXXx (ORCPT + 99 others); Thu, 19 Nov 2020 18:23:53 -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----- --=-=-=--