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 793CFC4167D for ; Mon, 6 Nov 2023 07:10:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0418C44017B; Mon, 6 Nov 2023 02:10:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F3462440150; Mon, 6 Nov 2023 02:10:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E239244017B; Mon, 6 Nov 2023 02:10:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D37F4440150 for ; Mon, 6 Nov 2023 02:10:13 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ADE98C06A8 for ; Mon, 6 Nov 2023 07:10:13 +0000 (UTC) X-FDA: 81426655506.11.D2A8796 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf16.hostedemail.com (Postfix) with ESMTP id ECBED18000E for ; Mon, 6 Nov 2023 07:10:11 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf16.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699254612; 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; bh=CAaRYEXwqQyq3T8nXdYNLgrRKXs7kLh0b6ILpZTQkk8=; b=Rix+I9EP912iBIjkm2FIJBGlkG27B0lRTXR/vVYuMaheprQDzl4jZHzTm9Nei1t3+r/t7C /3eq17PHKfQZL2QcPxi4k5UX/lPxHkMPS6QsBu6OJyuf4enseqkkBU02ffS1/23beqbgw9 X6zJQVs90OOWVMKyQMW1d7Jj+SjERPA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf16.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699254612; a=rsa-sha256; cv=none; b=onY6sSXVbWayDkkqLfwAfScFj2cHoCgaoLUYYVjeVs2WT6ro0mkABthjUCQKfbCxalP9tG ak3/16xQjEVxlk6kbINIla28MR+pM6h9oOnc7xkAthX3P2HzcsvbwxzB1U8Dpi21Z4RCvY OqtqWRyBssKT2RcCYhoAcd3gqyY60M8= Received: by verein.lst.de (Postfix, from userid 2407) id 7AFC868AA6; Mon, 6 Nov 2023 08:10:08 +0100 (CET) Date: Mon, 6 Nov 2023 08:10:08 +0100 From: Christoph Hellwig To: Keith Busch Cc: Mikulas Patocka , Marek Marczykowski-G'orecki , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Jan Kara , Vlastimil Babka , Andrew Morton , Matthew Wilcox , Michal Hocko , stable@vger.kernel.org, regressions@lists.linux.dev, Alasdair Kergon , Mike Snitzer , dm-devel@lists.linux.dev, linux-mm@kvack.org Subject: Re: Intermittent storage (dm-crypt?) freeze - regression 6.4->6.5 Message-ID: <20231106071008.GB17022@lst.de> References: <3cb4133c-b6db-9187-a678-11ed8c9456e@redhat.com> <11a9886d-316c-edcd-d6da-24ad0b9a2b4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: ECBED18000E X-Stat-Signature: mzaa8std5pjkjguiaccj1sixbrhp3nz7 X-HE-Tag: 1699254611-236121 X-HE-Meta: U2FsdGVkX1+60KTN4NCPnJMJKmFaHIiIz0L+XyYzf1+ACB6lQbZw8y7bexLG6cPjWWTxREIiO45VKOJ2nLk3eBHEg23E+VpLYZwWsu7bNm0MNaUEQhbxmKTKs4DCDvRXtBstuVA9jNUq2kbSioViL5YNqE8ndVX8om19BC3SLAAxykhneUgnu+sLiFB2sSxppNdj10Zx2MnvBXxWxOxHeSCFi04pUnnxjbJ2Hhx4atxjoVg0H1/BzC7HXPeeE5cfBMBSXorDgZeNoOBzZNpLccK45aCnl/Su102GzcAEgv0LPxiswKTuGC1mLQDb9rEV0paGwJ8ML/7GQjqicmo3mM25aOMpY8ns2u/KVxw2/epFdeDZRkaFzYLy7KtJIwW+VCn6kv/o+brRIIiwtLGpag9eKIlhXa8eZMM8wvHR6HjIN6XIeiQjaH5bfXIlK7uXYX7C4W3tAPjRiPnb/4csLvsks5pNiXTi91upA0YRg8PtY+wn3fweKRkvDtTE0elRGofUPw440zqPDcq57IiZtDAZGKLnkZ/OLGYWjWjzABQAy65BKUO+F8GwiOYVwTSMNAwlimkkOjBMJNrTQlopMmdcssi2Y0zpn2hDlGG5YWOuV27uW4rh0uYAmudfAKmOmBvMi1BxlfRWo4y+2RZhrQL5HPIQm3KXGff2jX2pVXwUGigxxNbu/o7wZPxJxMocyG8aOKrCfhtiRuJqshKPty0TOIvbYcpp+oUM6VHPCS020KKuiFvqis+xMijz5hSTkzmhoNf2up39TFeAwM2EiaKd5QrT0I7+KWxkzgB5S8LSFEcR5wziD/I0u0UznA+KUki0xm1SKuz8+/nHaTN5OIo011Lvp1PDpr3h6CwHJhu9wAlKOYgCbu8ZL4X1XCfGBftJfZc5sJ2xAhufVdKW7Z5okUYn6Fa+qJKk2gonUgGIkroPVg3U6OmYwrtUruwzH5+nyzc0Zu8KAxa8CrV Qy9t2XMs TWCa8TbvfUWjovWTgxwJnsfEYeAWFgrarZPz/rVO7tiXTGjxFRsLs9MycA/iDft9JaGMn6LJxCu7/X/rYNgtxjUa9l6QtXJFuLv2TqpBD3JhuA6o= 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 Sat, Nov 04, 2023 at 07:59:06AM -0600, Keith Busch wrote: > > dma_opt_mapping_size returns "min(dma_max_mapping_size(dev), size)". So > > you don't have to call dma_max_mapping_size explicitly, you can leave the > > file drivers/nvme/host/pci.c as it is. > > Indeed. > > > What about the other block device drivers (AHCI, SCSI...)? Should there be > > some generic framework that restricts max_hw_sectors according to > > dma_opt_mapping_size? > > I think it's just like any other request_queue limits and the individual > drivers have to set up these. Yes, or in case of SCSI the scsi midlayer, which already does it. The block layer itself doesn't even know that we're using DMA to transfer data. > Thinking on this again, this feels more like a max_segment_size limit > rather than a max_hw_sectors. No, it's an overall limit. If we'd have a lot of segments using the max size we'd still starve the swiotlb pool.