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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09DFECD5BDD for ; Fri, 6 Sep 2024 11:24:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F3726B0085; Fri, 6 Sep 2024 07:24:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A35E6B0088; Fri, 6 Sep 2024 07:24:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 692026B0089; Fri, 6 Sep 2024 07:24:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 51CC86B0085 for ; Fri, 6 Sep 2024 07:24:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CB13F4136B for ; Fri, 6 Sep 2024 11:24:12 +0000 (UTC) X-FDA: 82534079544.26.3968803 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id EFBA78000C for ; Fri, 6 Sep 2024 11:24:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I2VreqVp; spf=pass (imf02.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725621801; a=rsa-sha256; cv=none; b=gB6PjXAnC5QXx4El2KLZCEDhQoOARCgKcis6NkiE5AG3thVihLkqsM0YiTBfHX1E7GbYG+ pDYUZFudh5KeStt7WOJ/vWJzM7xT+9kuF+74nTvOxDcI1IScAdq+9Zaq78TPwDTbOGHsvh zUIRiHAeAOPPVQ4dvJR1/INXUX/AJ/w= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I2VreqVp; spf=pass (imf02.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725621801; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4Sh7NNRzd/yNJ6l4v6+y7Ry9bwNbYl8mvsIbShOjOiw=; b=yImu9c8p8vDJv9rEgl/QrVhIlEUAMMeJsakvk7fric/keY3bzUPaesOcVe8RnSzMDqhMMM KXHbSZhl/z/PPowAGM1J/HxG9gFeJlVCoVgQFvlD4k/kXKngIwcMm6ZJoYBq6tvC6vl+vz /KoFyzp6RbhlfxFNH1vS52XE2Moqf+0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725621850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4Sh7NNRzd/yNJ6l4v6+y7Ry9bwNbYl8mvsIbShOjOiw=; b=I2VreqVp0kFe6H6+ASTXYvz8ksR1eAQJpQ5AMNSqYXeL+j3gYVOHGPnJHCIfbSV1VLZb5y TK41LWvLdEuD3+ajCmp+B/U8lJIZcL58gONoQH0CAbuaKQb5ul2Nlq6k2j4LrJf2ygWANF jRcwbxJJDTEcmLgd8qfSOCyR3O10gLs= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-599-YoqNuUw4N1KYGO138DZNNQ-1; Fri, 06 Sep 2024 07:24:05 -0400 X-MC-Unique: YoqNuUw4N1KYGO138DZNNQ-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 389EB1955F68; Fri, 6 Sep 2024 11:24:03 +0000 (UTC) Received: from [10.45.224.222] (unknown [10.45.224.222]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 096C23000236; Fri, 6 Sep 2024 11:23:59 +0000 (UTC) Date: Fri, 6 Sep 2024 13:23:57 +0200 (CEST) From: Mikulas Patocka To: Tejun Heo cc: Mike Snitzer , Eric Biggers , dm-devel@lists.linux.dev, Alasdair Kergon , Lai Jiangshan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sami Tolvanen , linux-nfs@vger.kernel.org Subject: Re: sharing rescuer threads when WQ_MEM_RECLAIM needed? [was: Re: dm verity: don't use WQ_MEM_RECLAIM] In-Reply-To: Message-ID: <9d380772-6287-b75d-2d4d-e1c9a69ea981@redhat.com> References: <20240904040444.56070-1-ebiggers@kernel.org> <086a76c4-98da-d9d1-9f2f-6249c3d55fe9@redhat.com> <20240905223555.GA1512@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Stat-Signature: ngkugtz6bjked9889t51dcw7h7mh4t6m X-Rspamd-Queue-Id: EFBA78000C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725621850-735869 X-HE-Meta: U2FsdGVkX1/OMwJcoAPhL7JB5/0RsRyq2l7Wv/QAlCtg0m7vDvRy6Bismg644iPycHvFF4nKZBQs04cl+vZ2x5st2CHC7fCf94TGrIltZQ8cRvtoGxdk8lIGvSCzNPAGaTINW+89VSkufxINgVT9Y+bct0y5FiNBM6oKL1xHq4vHpmOtRuKWVKI4Scb2avxe4gi17r5aFKYdm1iKeVE13JWX7p9Eh+mWDv66igR95AhkqrkJ1yB19X+wc0MrJeg9pR13Df623LxawsBPM5w+AWFTKdwpyv8nRIlpMx0soclF9oosEukQ90tvEPpY3OcjPfACjv+wArfUo8VUocJ7118+xkwOqn4XNwvuA9PZwBfKc+t/Znvylo+KuRFK39IRffq8aFxNzZQMC2ojHGbkYEU+oTMQ5gLSjy3up2/qVxRK+9KGQd1BKiaBLoYSdihO0HFy6TkO2wkZnjb8AEUwCivVHSoKYTJFgfbcZ4umrbJKcs11TBle3m6RD6qkDOA6w3bzUxU7YdE8oVHNP5lSPIHBcjo7geTr4WhIfieEW7jPTw/5NyicX54vtldpMdnjbp1in7W+awp8BD8IaSleG9n4MwN413xTVgvWZyYSGF3YzODW5/m71uZYCcKnhtHNZmFZ1xkN8DWlcaNpynerEFR9tHqEGmo1XbGP5sGryzp8xWzlBUZDFYNMZMu933IpTfY11kbnXPG5+uZ4cszhh6n8NDm3eNcv2wL2twpclvM/ptOLNejhXiahI6VzDO3CUEQdMBtIoxtrL5nFySkzgE6DfsGP7osglGI3Q6NYTHWlm8FbKM3wDZEUSAkKO38jrUR9/vH7xOrABiOX2x33kRQ2SOMwt4QYqaKp+Aahh4qNxlmEdqt8WW5zsdEx4jMYK8dFq+OGYc8kXFc3DsOR5t0r3x57W8V+r4UjzrtShwGiEkVSeMD0NOYO2EIjaNg0cDVC8Drr/rqdewqH81e ej9mcJ9e 957PrQ8j/6FROW5JRn26qO9WTLh/APHWYNplRcOJpMwXFPYSmPXFi7Y1BVeEAUNnTw0dKi7tiE1TGfFuZMNitxW2wJojanWuw+G9O3iSn3vKsl1vpUEsAkwoycPgsJPGQOhiLqpx2ptfqwaxkdpl0k+Wkbl6l3rDhRvvoXyYDEPN9qBZrm6q2hWY5d4oQRqRn2qVvp9J41LVavl5HeY5ICH5CpKPPUsK/GPZiQmmupslaOCo4Hpo62xg7KRRFB/K5m/WR9oUJIJCjXQUCER/t57Pe4b1pb+LJzRRW/1h5ppVQuDWWag6BZfTR0wr/pRaj/uhj3FQzAGlAReBbN6ZmMyGWWJv6rw/vd5+UOM2jDg+EEUgNsubnaEOA1YTkUVhlytlEm7eXx9HtSSTh9ytuWgwAQA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 5 Sep 2024, Tejun Heo wrote: > Hello, > > On Thu, Sep 05, 2024 at 07:35:41PM -0400, Mike Snitzer wrote: > ... > > > I wonder if there's any way to safely share the rescuer threads. > > > > Oh, I like that idea, yes please! (would be surprised if it exists, > > but I love being surprised!). Like Mikulas pointed out, we have had > > to deal with fundamental deadlocks due to resource sharing in DM. > > Hence the need for guaranteed forward progress that only > > WQ_MEM_RECLAIM can provide. I remember that one of the first thing that I did when I started at Red Hat was to remove shared resources from device mapper :) There were shared mempools and shared kernel threads. You can see this piece of code in mm/mempool.c that was a workaround for shared mempool bugs: /* * FIXME: this should be io_schedule(). The timeout is there as a * workaround for some DM problems in 2.6.18. */ io_schedule_timeout(5*HZ); > The most straightforward way to do this would be simply sharing the > workqueue across the entities that wanna be in the same forward progress > guarantee domain. It shouldn't be that difficult to make workqueues share a > rescuer either but may be a bit of an overkill. > > Taking a step back tho, how would you determine which ones can share a > rescuer? Things which stack on top of each other can't share the rescuer cuz > higher layer occupying the rescuer and stall lower layers and thus deadlock. > The rescuers can be shared across independent stacks of dm devices but that > sounds like that will probably involve some graph walking. Also, is this a > real problem? > > Thanks. It would be nice if we could know dependencies of every Linux driver. But we are not quite there. We know the dependencies inside device mapper, but when you use some non-dm device (like md, loop), we don't have a dependecy graph for that. Mikulas