From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6507A2F12AF; Thu, 26 Feb 2026 22:04:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772143460; cv=none; b=jAqpfvgy1kILr/dc+/TBbLW+lYz8ciFhh/kbjd4dDOnZR+ZsaeA1VPI05xWdX/Tp5LMNYzwqfC2eQ+KKpBv+mgVmMTbIRdv31qhHa1OwNbQayuGmUTuB3X59B5njD4tJ4hjMvC/JSqzRvPbKEIwO1K7tSmpsCdYHQMIesVuYb0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772143460; c=relaxed/simple; bh=soc/yo1tEWGXbBjVrQ/VMOQ1ekNyzhkHjV9HavtUPDo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y/3VBj96qbkRsl3PM+iTSKy71ieI36JdUVGnH24djezgZS/2MDgUnBpr44Mz3ucGIyMpjMT0AAgPY9x19Tx66FwqygqQxUiS9olbMJ00W//xf0ena1v8IFDym8YArvDTithKcRTmxMA63n6+nsAuZOcSUfL4aN3NgAmAN3SNxBI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=bmFMChbe; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="bmFMChbe" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5bu012TDyQPUO/wvA+hw2yCZC4iVJmbX0faG8R4aVOY=; b=bmFMChbeXAKmL9O3h8bmg/4rBu So6ch1NZnvPbScRns188h7F/rGcpYLcQKPAND1O3tIhaTGfhesfRyaEMSiOck1t/7GJsgSW8By+oe I+6h8JlmxarQ7tRM8QL1c2VrCrvGumCicDKwneDLTqcbq1r6v3CDKHoyLopBGteCJSC60/gK3Y1Yk MRRGFix+j8wkBUHPxiSbKO/MbA5YC5+uJtdTB0P2eoY48gBiPsdaoS5Qu4rfUdcP7hGztuzf9N5u4 12HyGuT1qf4DoCAjblkVAff52JDrreI7lolCOWuTuFqA/U3Nt/x3bhEUV4uHKYQsn6JOd0Y6uf9QB Nm0hpEWQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvjSr-00000007HXz-3kME; Thu, 26 Feb 2026 22:04:09 +0000 Date: Thu, 26 Feb 2026 14:04:09 -0800 From: Christoph Hellwig To: Jens Axboe Cc: Tal Zussman , "Tigran A. Aivazian" , Alexander Viro , Christian Brauner , Jan Kara , Namjae Jeon , Sungjong Seo , Yuezhang Mo , Dave Kleikamp , Ryusuke Konishi , Viacheslav Dubeyko , Konstantin Komarov , Bob Copeland , "Matthew Wilcox (Oracle)" , Andrew Morton , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-nilfs@vger.kernel.org, ntfs3@lists.linux.dev, linux-karma-devel@lists.sourceforge.net, linux-mm@kvack.org, "Darrick J. Wong" Subject: Re: [PATCH RFC v2 1/2] filemap: defer dropbehind invalidation from IRQ context Message-ID: References: <20260225-blk-dontcache-v2-0-70e7ac4f7108@columbia.edu> <20260225-blk-dontcache-v2-1-70e7ac4f7108@columbia.edu> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Feb 25, 2026 at 03:52:41PM -0700, Jens Axboe wrote: > One solution could potentially be to use per-cpu lists for this. If you > have N threads working on separate block devices, they will tend to be > sticky to their CPU anyway. Having per-cpu lists would be nice, but I'd really love to have them in iomap, as we have quite a few iomap features that would benefit from generic offload to user context on completion. Right now we only have code for that in XFS, and that's because the list is anchored in the inode. Based on the commit message in cb357bf3d105f that's intentional for the write completions there, but for all other completions a generic per-cpu list would probably work fine.