From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) (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 A47D3318EC9 for ; Wed, 13 May 2026 02:15:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778638509; cv=none; b=eQBfn3tyZXW71e4R2JRyHnd5FcQBfJ0WMmeqzwDelQmWWZ0R90a+GRdPweUA/EXvL4kqnlkWi/WThgoabU+ijDaH2Miwnu23awGhDiw9f1N9pAqaJ1Uho/FC72EPfMHCU35lNHrLbVEqbV3zJakCn8oUB8ZxaTnZ8BKJw/rBQq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778638509; c=relaxed/simple; bh=tlu7E9a42EdO8Zb4bF9ZEOeSFpy0O6JOTEoFq9gBpMQ=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=NPxx0YZRNK0P7hvgFO1057ZDBCNohOqVV0IZIlekrvN+T5LBsonzQMAEwkZ+tgHIvL0gNyBw6fqcdsO0rbQg037UcNb/b32OKNc6qRZdXcV6ti87vdhTvl85EV6cKKnQ+YRuf9z919uZkHlAyu5LWby8lV4VjxaRyQY9wZW/Yj8= 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.175 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-f175.google.com with SMTP id 41be03b00d2f7-c80170db7d6so2380868a12.0 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=Ce/RT1WZaQ1RWFfIUXZwMGjZtv1lbi1W1lCXhtY8svjgGHdUq+eD1VbHblE9BgQA7E GR7S0rM5O6zbYVsp0oBdXV3O3kIMS60HpO6MWUfJrPm220XWUDCStLQzRs1Bh+R0yzQ9 +B4CheoZO97TG1NqOEB192CH7c9lnhIh6VWK5HERrFOKjctLuf9fTX8sJFk/ZGyWcGXQ mE0Bjlf2qQx5pUeke2jFu7mWM9lP0HndNHSkVI2PrBeUo/m48KngcR8s4dGX31UEXypE WrStrVPBYD09Gf9dig7DeaujYANcpvCUW1IcwqAJTmmg+DCAU46JAmB0C6m7hPDpW8rW wjyg== X-Forwarded-Encrypted: i=1; AFNElJ9mY03JfsBmSP0UNyfZrTE+PoGYsgnIsPoIqBxCQ+/RBBpXwfH9lJNlKfNuKiZ+7TWhUIEizoA9K8/HYX0=@vger.kernel.org X-Gm-Message-State: AOJu0Yyxc4ChPti7TI3GpAnBAjoiWVrlwcAbncJHes8KOEaxtY6o8Q+0 wTT1NtzDVlY2CCmrPWuGkhjRh1FOwIz/3z+xNgoFjv3QAlPQwxmLF53A X-Gm-Gg: Acq92OFQY8ECpean3a9il6Ehbwj69GrRjZBxJRPZyBAbWWIVncpDMzf5pB+Nc6QXnmK 30k9YGiuO1AVdtjbpw/2QRKAoeZp3sUVJI+o8U5fy5CoRWzeb3l4jLWF2wa5gKTVnz4FvcW/3C0 o2ztIPBY1fJd+7GvtVTpfXPLa4ybbajOD9TFeEu1EdN86MABASlojujSuP7fFVoWJlxjncg19v4 yRsfW+5zNCjFf1gCRwEPwEKr7TrZ/0NbHnlUFzJyuLnxklUAFRBeOAOQHQft9uDQ29V3umRcEda DZpE3wz8eHONm4D0Et0m+Ob/YRfK6xoui35lLooNdK48e8pBxxpAIcymsbDx5A7vMFrhbBG9SKT dwlf1JMal8XeR/qt4SZkEENDQjsMRtKjeZvKcHTRNkbQO08xuTaiX9+vG+IVR57Jr9hdK3dzcgZ 9ZRRNjxr4v5HjUsIr7RP4QXw== 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-kernel@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)