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 096382DC357; Thu, 2 Apr 2026 05:21:43 +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=1775107305; cv=none; b=Y/AMinGzCnDqc4kA4N7QyWWltRkctshHY74CIBvSnPmyCjsho2FX48cnJl7AyQa4ZfpiIN/VmYfPi5RXIusiieRjsDjU5idRgAJlp0C8DO893V7JqC3Vge434KRAVQA+TkLkqLxbzGEnYr4kqaRTz2mJQ8h6t11/DdeugSA8G70= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775107305; c=relaxed/simple; bh=uqsYExntEu7voInGnB9t7fPXObZlfXDNPSo+6w322k8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g/jGvG2UvSy0/hvcZizMevPxb/j407ZyO8D4XQS8seCCtgLclsOTT/UjpHyHZUE/ioqHLtijbd2CmqipVD4gDSxQEu3FsxqhwpH99nQT7XbHU5EQ5LDWsrfr6r7igBSuRU43YUnYopTMTL33a+F+j0jxfkAn33DGCNtPynQo0Eo= 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=yr11Fpu6; 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="yr11Fpu6" 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=kCTASolh/HHAKZfZX4Vdxe/7xfbsKFH4aqSmS0b3nPo=; b=yr11Fpu6FYIB0gkBujQ/3cI/ow yusMImjUDC/ox8LjAXPIaKbbc1Pvw+z/Pn77dW7GJdmFeJgXa+SwNmJcU06iqbjRwmt/XoL+IasqC fx3BpLLBamutD2gd16LTG3yitc0ythc2C+ei9CDMOaWoWlkU7Iq7dSR62PRgTQqizQ73jifgEYaz4 JjlNUhETfHQM77crjIGx2pQtdEHTgNyXsW2PbJIHrQsnVDKSjsPaV8dUdadEZ0K3jIQphcMNXW2DB vaxRh/UD0TgnOUgxRpXh1g4pjka94XYL00h/JMC32NjTzEMWxWpcJcJSe1bxnkVeVCC07fxIGqcK5 pl0lV7Kg==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1w8AUu-0000000GnzB-0dij; Thu, 02 Apr 2026 05:21:40 +0000 Date: Wed, 1 Apr 2026 22:21:40 -0700 From: Christoph Hellwig To: Jeff Layton Cc: Alexander Viro , Christian Brauner , Jan Kara , "Matthew Wilcox (Oracle)" , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Mike Snitzer , Chuck Lever , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/4] mm: fix IOCB_DONTCACHE write performance with rate-limited writeback Message-ID: References: <20260401-dontcache-v1-0-1f5746fab47a@kernel.org> <20260401-dontcache-v1-1-1f5746fab47a@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@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: <20260401-dontcache-v1-1-1f5746fab47a@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Apr 01, 2026 at 03:10:58PM -0400, Jeff Layton wrote: > IOCB_DONTCACHE calls filemap_flush_range() with nr_to_write=LONG_MAX > on every write, which flushes all dirty pages in the written range. > > Under concurrent writers this creates severe serialization on the > writeback submission path, causing throughput to collapse to ~47% of > buffered I/O with multi-second tail latency. Even single-client > sequential writes suffer: on a 512GB file with 256GB RAM, the > aggressive flushing triggers dirty throttling that limits throughput > to 575 MB/s vs 1442 MB/s with rate-limited writeback. I'm not sure the first how you think the first paragraph relate to the second. > Replace the filemap_flush_range() call in generic_write_sync() with a > new filemap_dontcache_writeback_range() that uses two rate-limiting > mechanisms: > > 1. Skip-if-busy: check mapping_tagged(PAGECACHE_TAG_WRITEBACK) > before flushing. If writeback is already in progress on the > mapping, skip the flush entirely. This eliminates writeback > submission contention between concurrent writers. Makes sense. > 2. Proportional cap: when flushing does occur, cap nr_to_write to > the number of pages just written. This prevents any single > write from triggering a large flush that would starve concurrent > readers. This doesn't make any sense at all. filemap_flush_range/filemap_writeback always caps the number of written pages to the range passed in. What do you think is the change here? > + return filemap_writeback(mapping, start, end, WB_SYNC_NONE, &nr, > + WB_REASON_BACKGROUND); filemap_writeback only has 5 arguments in any tree I've looked at including linux-next.