From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 89C6730674A for ; Wed, 13 May 2026 02:15:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778638508; cv=none; b=aszNEwlVq4Y+aVAYDFtV2zswDl8zOxgU/9Vs/8WByZeHU9DTtfvdZ61FirlGD1FCRUkwMwDiDhpE9cU9Yu2UbbNO99V/iafJdsZ78t8LH8XAK3HjJK/DllaGn0RgbpwGW4cx1hMYN43+Z8GLtHXr1Phl0CqxjAv3cRheizAYQ/Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778638508; c=relaxed/simple; bh=tlu7E9a42EdO8Zb4bF9ZEOeSFpy0O6JOTEoFq9gBpMQ=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=ocZo4RiVWh8iOJxKO9BLNQpuuaJ6aP+DLvfpJXWtqosShZt4HY7jXH8JoN1xs3pCTuaLi4MMfXNc4SmmM7tauJNzqasme+bmbUXd0ORWx/VYWR00yEfXFPUaLa553LgRifoteo+eBtJ7GsvmUqtrykOGD6TLhkihoLtbLYMdV4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=i6LDV1b5; arc=none smtp.client-ip=209.85.215.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i6LDV1b5" Received: by mail-pg1-f177.google.com with SMTP id 41be03b00d2f7-c70ea5e9e9dso2574573a12.1 for ; Tue, 12 May 2026 19:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778638507; x=1779243307; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=tlu7E9a42EdO8Zb4bF9ZEOeSFpy0O6JOTEoFq9gBpMQ=; b=i6LDV1b5mDErIAzCZK+iwWh5MUCar4bpILro7zX9pTN0yUCPqzYDVH4TfwcTJSVap/ +xUcCunJ4mH6723+FhnZC/rFGauFP9aORGliDejy780K/tloDiLAAauUxMstXxezQDHw RCZKZ/JlQxlcKG5qC1r0IiNux7j7ZNl9F0Jv5foLyXLYrzHO4a+lgNpOctfP4GIyNhmh IJmI2/0iZ2RSwXOd/w+ZlioLw5H5sZPXs3xm/c1/uODdO9OHWNAEdumj9/qLuXECbTB3 drOiXf2RltrVljku4icerrE4d5FFMIIiU/3URQahhmA3xf9J7+djv3j8i2C6L1oq6hR0 XghQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778638507; x=1779243307; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tlu7E9a42EdO8Zb4bF9ZEOeSFpy0O6JOTEoFq9gBpMQ=; b=UQkjTa/0Lsb0UoRXvS7gOqi/Buxb2tbRrxezxZVT/WvRDq2qYNgpr5GM8pbefJQiPu 8qSqeEA2KWLvrJvKa42/i+mkkUL0KB5I8JGjdTxZyNCD6gTTw6Z1+9ctgS4vFbKbRrKr 5Hz7nx3U5dsdbhqtQT9W1PPnyamHXfLQbxDF/WTuv+ICA+wze3x54UF5dSal7h3pwZU3 YZm16ADqy172uu64fF+L+N+9wNvMeoeTYHuYr6hwybMhddsekWCHz2OX2eNKZn14tTBz MbC0oXcrDyY7ritC1DiR9kVr3drBFFjJyGHnoLDpu65RYdLwMqFTMoKWZJyJl+RjAod8 u5yQ== X-Gm-Message-State: AOJu0Yy94wOFWLwImUnyqMdjeXosI4iOIauLKjF+RyRrH3gVEVTloz53 O2wpO7IWlPZcNmyzbaYVBdBr24wXM7CkMc23nROl2sxwpclgKGXzhhWT X-Gm-Gg: Acq92OEwRtbl0s+QcFDjpNJECz5vzKpuHjPX1GZ0DF299f4m0F00UCGe1SCmS4kGxey NYTDl7dYKLR+bgsqfq2CM0RApFEtNTq8HM550qrYNeDBMYu3hCWaYKLJnxot6YWWSXdj9hPYDfI /Y7E+pQ4UoSYLwkDMPA0WG1eD8FTLER0bh+MeqVejD1spYWdaORgRU4Yb3CTkY8ohhzMjBAUk+7 dh1VdcRtJ+RX5IouQZ3SS9YDfz7xu+c/mkZWxFFuZ/1H5Z4bERFYO54Cnuand2gbW5Fo481kTB0 JqpgSXGdqSmGeb4rfu8ieoUguEBc1Dau6PASn76XzymzCCk2d64R7MmwjdXCPu2bCI7dHUHmQ/h EaELGzmW5I7sdmFsJiTIMfXLRUwKs6oM+n55gRvVGX4XLrwl9VOkM0tZSQiN0WpUe9oTqYrnbon DS7d0mmAazrzZinS1r8NqhcA== X-Received: by 2002:a05:6a20:7346:b0:39e:f6bb:48f9 with SMTP id adf61e73a8af0-3af80a70ee5mr1215571637.15.1778638506562; Tue, 12 May 2026 19:15:06 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c826767bf53sm13040829a12.6.2026.05.12.19.14.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 19:15:05 -0700 (PDT) From: Ritesh Harjani (IBM) To: Jeff Layton , 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 , Jens Axboe , Chuck Lever Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, Jeff Layton Subject: Re: [PATCH v7 2/3] mm: track DONTCACHE dirty pages per bdi_writeback In-Reply-To: <20260511-dontcache-v7-2-2848ddce8090@kernel.org> Date: Wed, 13 May 2026 07:37:06 +0530 Message-ID: References: <20260511-dontcache-v7-0-2848ddce8090@kernel.org> <20260511-dontcache-v7-2-2848ddce8090@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Jeff Layton writes: > Add a per-wb WB_DONTCACHE_DIRTY counter that tracks the number of dirty > pages with the dropbehind flag set (i.e., pages dirtied via RWF_DONTCACHE > writes). > > Increment the counter alongside WB_RECLAIMABLE in folio_account_dirtied() > when the folio has the dropbehind flag set, and decrement it in > folio_clear_dirty_for_io() and folio_account_cleaned(). Also decrement it > when a non-DONTCACHE lookup atomically clears the dropbehind flag on a > dirty folio in __filemap_get_folio_mpol(), using folio_test_clear_dropbehind() > to prevent concurrent lookups from double-decrementing the counter, and > guarding the decrement with mapping_can_writeback() to match the increment > path. > > Transfer the counter alongside WB_RECLAIMABLE in inode_do_switch_wbs() so > that the stat is properly migrated when an inode switches cgroup writeback > domains. > > The counter will be used by the writeback flusher to determine how many > pages to write back when expediting writeback for IOCB_DONTCACHE writes, > without flushing the entire BDI's dirty pages. > Using wb_stat infra was a clever thing to do for counting the number of dontcache folios. I see that we don't collect DONTCACHE stats in collect_wb_stats(), which I guess, is mainly for debug purposes only. Either ways I am not sure how useful that might be, since it only shows the approximate stats since it doesn't do wb_stat_sum() for most of the other stats too. If for any reason we need that in future, that could go in a separate patch. For this patch - LGTM. Please feel free to add: Reviewed-by: Ritesh Harjani (IBM)