Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1277215ybv; Thu, 13 Feb 2020 19:48:11 -0800 (PST) X-Google-Smtp-Source: APXvYqya40ftonyrGvJHXifl0dxMPplmB1Sg3vAtPsAJccpp6qOQTMphnwwp0pN1/bdHXWZtXyjF X-Received: by 2002:a05:6830:22e2:: with SMTP id t2mr660518otc.129.1581652091400; Thu, 13 Feb 2020 19:48:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581652091; cv=none; d=google.com; s=arc-20160816; b=q00fWKMiz34hxVYCPe8PpvXgVPS/2WqcHYVGDwiymKZi4m4NJlT8f0vIRrOcc88Xgv R8iBPk1zXwErrF5Wa5YOFaiuTAtKmVG2DCS6OcY3JMM+RRC/bfVfRAWdLGvhHpV1tJ79 UfigsaZUWDw5AWUjEpdlT1rBFp1KVVpTrGFGtvQUIBFXcAqGLuiOOLoIf74j5Tw8i8fe YtdEAjyUa56jncgqbPIXidgmIoRNldT9mouhbJL8Qrw1Qh4FEI0evjv4OXppzlFjHuEU bku380nqRbD5W5h83/Pq2sV6amzcHo0gXFvaHcz2MRqRYebJpvPIJW09tsiAke6gLO8h Lk/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:to:subject; bh=HZ2RR+9MW447q7xKt/FDmJSS48yGW7WVgt/o5wqn98A=; b=gqINgi5OU/f/rdKmqxMvWVfaCouCjQp1NofoWvNGL2u4XYN/l1bRckJS0r9N6SoHi7 bY1ixayf2ePlm0i/tnRFwq+O9dEUvf1xHKrnwbhjOegxD+TOSM7lJ1V41MQz+Xmh2lAQ ujk5sDtccypZWcHF0QmmwgDKYQZ5CZ92bjp1MuCbXLruRpWvQGKSv6zaXsglMdW+S2o+ SPrLRyjVS54sVXxNHqHwUziXxYPsNKze2P8Wa38snM7585gZrFIueNnFcsdgf+4+59Dy gLZkZyBD0vSMg7jD4hB8rFYifVlHNe4IEHxeKCgBKx2sEuDpLClzI7y5+JLcvTFpqg2e yxzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l80si2130765oib.268.2020.02.13.19.47.59; Thu, 13 Feb 2020 19:48:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728479AbgBNDry (ORCPT + 99 others); Thu, 13 Feb 2020 22:47:54 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:56220 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728089AbgBNDrx (ORCPT ); Thu, 13 Feb 2020 22:47:53 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id C36B0383C2D9BD887B39; Fri, 14 Feb 2020 11:47:50 +0800 (CST) Received: from [127.0.0.1] (10.63.139.185) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.439.0; Fri, 14 Feb 2020 11:47:47 +0800 Subject: Re: [PATCH] Remove WQ_CPU_INTENSIVE flag from unbound wq's To: Maksym Planeta , Herbert Xu , "David S. Miller" , Alasdair Kergon , Mike Snitzer , , Song Liu , Gao Xiang , Chao Yu , , , , References: <20200213141823.2174236-1-mplaneta@os.inf.tu-dresden.de> From: Zhou Wang Message-ID: <5E461863.3000004@hisilicon.com> Date: Fri, 14 Feb 2020 11:47:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20200213141823.2174236-1-mplaneta@os.inf.tu-dresden.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.63.139.185] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/13 22:18, Maksym Planeta wrote: > The documentation [1] says that WQ_CPU_INTENSIVE is "meaningless" for > unbound wq. I remove this flag from places where unbound queue is > allocated. This is supposed to improve code readability. > > 1. https://www.kernel.org/doc/html/latest/core-api/workqueue.html#flags > > Signed-off-by: Maksym Planeta > --- > drivers/crypto/hisilicon/qm.c | 3 +-- > drivers/md/dm-crypt.c | 2 +- > drivers/md/dm-verity-target.c | 2 +- > drivers/md/raid5.c | 2 +- > fs/erofs/zdata.c | 2 +- > 5 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c > index b57da5ef8b5b..4a39cb2c6a0b 100644 > --- a/drivers/crypto/hisilicon/qm.c > +++ b/drivers/crypto/hisilicon/qm.c > @@ -1148,8 +1148,7 @@ struct hisi_qp *hisi_qm_create_qp(struct hisi_qm *qm, u8 alg_type) > qp->qp_id = qp_id; > qp->alg_type = alg_type; > INIT_WORK(&qp->work, qm_qp_work_func); > - qp->wq = alloc_workqueue("hisi_qm", WQ_UNBOUND | WQ_HIGHPRI | > - WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM, 0); > + qp->wq = alloc_workqueue("hisi_qm", WQ_UNBOUND | WQ_HIGHPRI | WQ_MEM_RECLAIM, 0); I am OK with qm code. Thanks! Zhou > if (!qp->wq) { > ret = -EFAULT; > goto err_free_qp_mem; > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index c6a529873d0f..44d56325fa27 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -3032,7 +3032,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv) > 1, devname); > else > cc->crypt_queue = alloc_workqueue("kcryptd/%s", > - WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND, > + WQ_MEM_RECLAIM | WQ_UNBOUND, > num_online_cpus(), devname); > if (!cc->crypt_queue) { > ti->error = "Couldn't create kcryptd queue"; > diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c > index 0d61e9c67986..20f92c7ea07e 100644 > --- a/drivers/md/dm-verity-target.c > +++ b/drivers/md/dm-verity-target.c > @@ -1190,7 +1190,7 @@ static int verity_ctr(struct dm_target *ti, unsigned argc, char **argv) > } > > /* WQ_UNBOUND greatly improves performance when running on ramdisk */ > - v->verify_wq = alloc_workqueue("kverityd", WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM | WQ_UNBOUND, num_online_cpus()); > + v->verify_wq = alloc_workqueue("kverityd", WQ_MEM_RECLAIM | WQ_UNBOUND, num_online_cpus()); > if (!v->verify_wq) { > ti->error = "Cannot allocate workqueue"; > r = -ENOMEM; > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index ba00e9877f02..cd93a1731b82 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -8481,7 +8481,7 @@ static int __init raid5_init(void) > int ret; > > raid5_wq = alloc_workqueue("raid5wq", > - WQ_UNBOUND|WQ_MEM_RECLAIM|WQ_CPU_INTENSIVE|WQ_SYSFS, 0); > + WQ_UNBOUND|WQ_MEM_RECLAIM|WQ_SYSFS, 0); > if (!raid5_wq) > return -ENOMEM; > > diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c > index 80e47f07d946..b2a679f720e9 100644 > --- a/fs/erofs/zdata.c > +++ b/fs/erofs/zdata.c > @@ -43,7 +43,7 @@ void z_erofs_exit_zip_subsystem(void) > static inline int z_erofs_init_workqueue(void) > { > const unsigned int onlinecpus = num_possible_cpus(); > - const unsigned int flags = WQ_UNBOUND | WQ_HIGHPRI | WQ_CPU_INTENSIVE; > + const unsigned int flags = WQ_UNBOUND | WQ_HIGHPRI; > > /* > * no need to spawn too many threads, limiting threads could minimum >