Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2468406pxb; Tue, 13 Apr 2021 02:38:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHuzZMCwgdrh8ScBIVr6MRDk7RkrRSbT2DodyZkTmZqYtSPINNmN7MPx+59QdfzRJqVlX7 X-Received: by 2002:a63:7e52:: with SMTP id o18mr31649631pgn.416.1618306731880; Tue, 13 Apr 2021 02:38:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618306731; cv=none; d=google.com; s=arc-20160816; b=FZ5bh32Oxiv2WYOfufmwj7Rli6wg183K5PHPq+kaSM3AN7SX0gSSFN5C9JPXyyJpO5 y+WUyDlwUuBE21bZq89/XmHqC61KgTbG2YWGrAWnBQpi4Y8IpMmYwWIuzyqA01wFtFiy u6y5CYP29RZaXZatDt8z5fxhCKniUDPh5yq6uRpZ4N/iq/ZleBCBjtSog9QVANEEAlJF iWde9U02lZxsbHRQ//zuS2b9pwYK4VX4qu6E32bNsZsYVL0eYYJ+E8JWx5HU83nZCRCj EoVF3io3UA8ETsz5iSr9zkEaaIpwzcPsAFAG/cTREBt9k+u5HTa797wp0D0mkSAzf/8N WHQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=034zy4yCs8jtPYNP+O2gdDkfdotDPhtBPZSnBJ2RVX4=; b=RNjHOGxbSgTvFmcKIFb5h3sEol7CuipgK1IAZt/k09s6mGMuAnflDRXumWXyiV5yr3 PVaYHHOeA533k3J4K8lhCbCmFwZZBKpGiTkTmM6nGV+i9LXp0k09a2BJQc566kLP2Di8 QnZNPVc9B4WzPKOoAHZx4gAyTBqtTL0RVti9Q6pqEaXRAnY0s+Fzk0XUhGiuIptYOocz t60c840B4CkigNya5OmKPKE2qUz769tuZjA7S+QnAKtbXUsHvjQPB457LoQ29KaygYDC aNOPml+CaY9zbzARlaH/ML9g/MVoFUVemQj016cTZENXoxF6gzqJjaxq/mcAhjXK7dfO aPAA== 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 d65si16644047pfc.60.2021.04.13.02.38.39; Tue, 13 Apr 2021 02:38:51 -0700 (PDT) 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 S243223AbhDMIy3 (ORCPT + 99 others); Tue, 13 Apr 2021 04:54:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:52188 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229867AbhDMIyZ (ORCPT ); Tue, 13 Apr 2021 04:54:25 -0400 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 82D69AF0E; Tue, 13 Apr 2021 08:54:05 +0000 (UTC) Date: Tue, 13 Apr 2021 10:54:04 +0200 From: Daniel Wagner To: Jason Gunthorpe Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Steve Wise , Leon Romanovsky , Potnuri Bharat Teja Subject: Re: [PATCH] nvme: Drop WQ_MEM_RECLAIM flag from core workqueues Message-ID: <20210413085404.tzam5lprtspwcek4@beryllium.lan> References: <20210412122330.5166-1-dwagner@suse.de> <20210412123149.GE227011@ziepe.ca> <20210412124909.olui5hfhceakt4u4@beryllium.lan> <20210412130402.GF227011@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210412130402.GF227011@ziepe.ca> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 12, 2021 at 10:04:02AM -0300, Jason Gunthorpe wrote: > Basically the allocation of importance in the workqueue is assigning a > worker, so pre-allocating a worker ensures the work can continue to > progress without becoming dependent on allocations. Ah okay, got it. I didn't really understood this part. So the WQ_MEM_RECLAIM is 'just' avoiding a new worker creation. > This is why work under the WQ_MEM_RECLAIM cannot recurse back into the > allocator as it would get a rescurer thread stuck at a point when all > other threads are already stuck. > > To remove WQ_MEM_RECLAIM you have to make assertions about the calling > contexts and blocking contexts of the workqueue, not what the work > itself is doing. Hmm, I am struggling with your last statement. If a worker does an allocation it might block. I understand this is something which a worker in a WQ_MEM_RECLAIM context is not allowed to do. My aim is still to get rid of the warning triggered by the rdma code. Anyway, thanks for explaining.