* [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter
@ 2025-06-25 15:51 Vlastimil Babka
2025-06-25 21:38 ` Joanne Koong
2025-07-07 14:14 ` Vlastimil Babka
0 siblings, 2 replies; 5+ messages in thread
From: Vlastimil Babka @ 2025-06-25 15:51 UTC (permalink / raw)
To: Andrew Morton, Matthew Wilcox (Oracle)
Cc: Tejun Heo, Maxim Patlasov, Jan Kara, Zach O'Keefe,
Jonathan Corbet, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Suren Baghdasaryan, Michal Hocko,
Kirill A. Shutemov, Brendan Jackman, Johannes Weiner, Zi Yan,
Joanne Koong, Jingbo Xu, Jeff Layton, Miklos Szeredi,
linux-kernel, linux-fsdevel, linux-doc, linux-mm, Jens Axboe,
Vlastimil Babka
The only user of the counter (FUSE) was removed in commit 0c58a97f919c
("fuse: remove tmp folio for writebacks and internal rb tree") so follow
the established pattern of removing the counter and hardcoding 0 in
meminfo output, as done recently with NR_BOUNCE. Update documentation
for procfs, including for the value for Bounce that was missed when
removing its counter.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
The removal of the counter is straightforward. The reason for the large
Cc list is that there is a comment in mm/page-writeback.c function
wb_position_ratio() that mentions NR_WRITEBACK_TEMP, and just deleting
the sentence feels to me it could be the wrong thing to do - maybe the
strictlimit feature itself is now obsolete? It sure does mention FUSE
as the main reason to exist, but commit 5a53748568f79 that introduced it
also mentions slow USB sticks as a possibile scenario. Has that
happened? I'm not familiar enough with this so I'd rather highlight this
and ask for input here than make "git grep NR_WRITEBACK_TEMP" return
nothing.
---
Documentation/filesystems/proc.rst | 8 +++++---
drivers/base/node.c | 2 +-
fs/proc/meminfo.c | 3 +--
include/linux/mmzone.h | 1 -
mm/show_mem.c | 2 --
mm/vmstat.c | 1 -
6 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 5236cb52e357dcd00496b26be8578e1dec0a345e..2971551b7235345c9a7ec3c84a87a16adcda5901 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -1196,12 +1196,14 @@ SecPageTables
Memory consumed by secondary page tables, this currently includes
KVM mmu and IOMMU allocations on x86 and arm64.
NFS_Unstable
- Always zero. Previous counted pages which had been written to
+ Always zero. Previously counted pages which had been written to
the server, but has not been committed to stable storage.
Bounce
- Memory used for block device "bounce buffers"
+ Always zero. Previously memory used for block device
+ "bounce buffers".
WritebackTmp
- Memory used by FUSE for temporary writeback buffers
+ Always zero. Previously memory used by FUSE for temporary
+ writeback buffers.
CommitLimit
Based on the overcommit ratio ('vm.overcommit_ratio'),
this is the total amount of memory currently available to
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 6d66382dae6533a0c8481f72ad67c35021e331d3..e434cb260e6182468e0d617b559134c6fbe128f4 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -500,7 +500,7 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(node_page_state(pgdat, NR_SECONDARY_PAGETABLE)),
nid, 0UL,
nid, 0UL,
- nid, K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
+ nid, 0UL,
nid, K(sreclaimable +
node_page_state(pgdat, NR_KERNEL_MISC_RECLAIMABLE)),
nid, K(sreclaimable + sunreclaimable),
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index bc2bc60c36ccc1dab8913913056f5ff20b448490..a458f1e112fdbc63019239a79ce39c5576b5f963 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -121,8 +121,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "NFS_Unstable: ", 0);
show_val_kb(m, "Bounce: ", 0);
- show_val_kb(m, "WritebackTmp: ",
- global_node_page_state(NR_WRITEBACK_TEMP));
+ show_val_kb(m, "WritebackTmp: ", 0);
show_val_kb(m, "CommitLimit: ", vm_commit_limit());
show_val_kb(m, "Committed_AS: ", committed);
seq_printf(m, "VmallocTotal: %8lu kB\n",
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 1d1bb2b7f40d25b430932c9ef9096d97bf1c29de..0c5da9141983b795018c0aa2457b065507416564 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -206,7 +206,6 @@ enum node_stat_item {
NR_FILE_PAGES,
NR_FILE_DIRTY,
NR_WRITEBACK,
- NR_WRITEBACK_TEMP, /* Writeback using temporary buffers */
NR_SHMEM, /* shmem pages (included tmpfs/GEM pages) */
NR_SHMEM_THPS,
NR_SHMEM_PMDMAPPED,
diff --git a/mm/show_mem.c b/mm/show_mem.c
index 0cf8bf5d832d6b339b4c9a6c7b8b3ab41683bcfe..41999e94a56d623726ea92f3f38785e8b218afe5 100644
--- a/mm/show_mem.c
+++ b/mm/show_mem.c
@@ -246,7 +246,6 @@ static void show_free_areas(unsigned int filter, nodemask_t *nodemask, int max_z
" shmem_pmdmapped:%lukB"
" anon_thp:%lukB"
#endif
- " writeback_tmp:%lukB"
" kernel_stack:%lukB"
#ifdef CONFIG_SHADOW_CALL_STACK
" shadow_call_stack:%lukB"
@@ -273,7 +272,6 @@ static void show_free_areas(unsigned int filter, nodemask_t *nodemask, int max_z
K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
K(node_page_state(pgdat, NR_ANON_THPS)),
#endif
- K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
node_page_state(pgdat, NR_KERNEL_STACK_KB),
#ifdef CONFIG_SHADOW_CALL_STACK
node_page_state(pgdat, NR_KERNEL_SCS_KB),
diff --git a/mm/vmstat.c b/mm/vmstat.c
index c3114b8826e4c3b6969fd4af4b0cd32173c42d7b..e0fcd9057f344170b2dc5c82beafea4ec18359bb 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1251,7 +1251,6 @@ const char * const vmstat_text[] = {
[I(NR_FILE_PAGES)] = "nr_file_pages",
[I(NR_FILE_DIRTY)] = "nr_dirty",
[I(NR_WRITEBACK)] = "nr_writeback",
- [I(NR_WRITEBACK_TEMP)] = "nr_writeback_temp",
[I(NR_SHMEM)] = "nr_shmem",
[I(NR_SHMEM_THPS)] = "nr_shmem_hugepages",
[I(NR_SHMEM_PMDMAPPED)] = "nr_shmem_pmdmapped",
---
base-commit: 4216fd45fc9156da0ee33fcb25cc0a5265049e32
change-id: 20250625-nr_writeback_removal-4eca139cf09a
Best regards,
--
Vlastimil Babka <vbabka@suse.cz>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter
2025-06-25 15:51 [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter Vlastimil Babka
@ 2025-06-25 21:38 ` Joanne Koong
2025-06-26 7:00 ` Jan Kara
2025-07-07 14:14 ` Vlastimil Babka
1 sibling, 1 reply; 5+ messages in thread
From: Joanne Koong @ 2025-06-25 21:38 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, Matthew Wilcox (Oracle), Tejun Heo, Maxim Patlasov,
Jan Kara, Zach O'Keefe, Jonathan Corbet, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Suren Baghdasaryan,
Michal Hocko, Kirill A. Shutemov, Brendan Jackman,
Johannes Weiner, Zi Yan, Jingbo Xu, Jeff Layton, Miklos Szeredi,
linux-kernel, linux-fsdevel, linux-doc, linux-mm, Jens Axboe
On Wed, Jun 25, 2025 at 8:51 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> The only user of the counter (FUSE) was removed in commit 0c58a97f919c
> ("fuse: remove tmp folio for writebacks and internal rb tree") so follow
> the established pattern of removing the counter and hardcoding 0 in
> meminfo output, as done recently with NR_BOUNCE. Update documentation
> for procfs, including for the value for Bounce that was missed when
> removing its counter.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> The removal of the counter is straightforward. The reason for the large
> Cc list is that there is a comment in mm/page-writeback.c function
> wb_position_ratio() that mentions NR_WRITEBACK_TEMP, and just deleting
> the sentence feels to me it could be the wrong thing to do - maybe the
> strictlimit feature itself is now obsolete? It sure does mention FUSE
> as the main reason to exist, but commit 5a53748568f79 that introduced it
> also mentions slow USB sticks as a possibile scenario. Has that
> happened? I'm not familiar enough with this so I'd rather highlight this
> and ask for input here than make "git grep NR_WRITEBACK_TEMP" return
> nothing.
My understanding is that even without the fuse use case, strictlimit
is still used for other devices via the /sys/class/bdi interface (eg
/sys/class/bdi/<bdi>/strict_limit) so I don't think the feature itself
is obsolete.
It's not clear to me whether fuse still needs strictlimit now that it
doesn't have tmp writeback pages, but it'd be great to get an answer
to this, as strictlimit currently leads to too much dirty throttling
when large folios are enabled in fuse.
> ---
> Documentation/filesystems/proc.rst | 8 +++++---
> drivers/base/node.c | 2 +-
> fs/proc/meminfo.c | 3 +--
> include/linux/mmzone.h | 1 -
> mm/show_mem.c | 2 --
> mm/vmstat.c | 1 -
> 6 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 5236cb52e357dcd00496b26be8578e1dec0a345e..2971551b7235345c9a7ec3c84a87a16adcda5901 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -1196,12 +1196,14 @@ SecPageTables
> Memory consumed by secondary page tables, this currently includes
> KVM mmu and IOMMU allocations on x86 and arm64.
> NFS_Unstable
> - Always zero. Previous counted pages which had been written to
> + Always zero. Previously counted pages which had been written to
> the server, but has not been committed to stable storage.
> Bounce
> - Memory used for block device "bounce buffers"
> + Always zero. Previously memory used for block device
> + "bounce buffers".
> WritebackTmp
> - Memory used by FUSE for temporary writeback buffers
> + Always zero. Previously memory used by FUSE for temporary
> + writeback buffers.
> CommitLimit
> Based on the overcommit ratio ('vm.overcommit_ratio'),
> this is the total amount of memory currently available to
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 6d66382dae6533a0c8481f72ad67c35021e331d3..e434cb260e6182468e0d617b559134c6fbe128f4 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -500,7 +500,7 @@ static ssize_t node_read_meminfo(struct device *dev,
> nid, K(node_page_state(pgdat, NR_SECONDARY_PAGETABLE)),
> nid, 0UL,
> nid, 0UL,
> - nid, K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
> + nid, 0UL,
> nid, K(sreclaimable +
> node_page_state(pgdat, NR_KERNEL_MISC_RECLAIMABLE)),
> nid, K(sreclaimable + sunreclaimable),
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index bc2bc60c36ccc1dab8913913056f5ff20b448490..a458f1e112fdbc63019239a79ce39c5576b5f963 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -121,8 +121,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>
> show_val_kb(m, "NFS_Unstable: ", 0);
> show_val_kb(m, "Bounce: ", 0);
> - show_val_kb(m, "WritebackTmp: ",
> - global_node_page_state(NR_WRITEBACK_TEMP));
> + show_val_kb(m, "WritebackTmp: ", 0);
> show_val_kb(m, "CommitLimit: ", vm_commit_limit());
> show_val_kb(m, "Committed_AS: ", committed);
> seq_printf(m, "VmallocTotal: %8lu kB\n",
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 1d1bb2b7f40d25b430932c9ef9096d97bf1c29de..0c5da9141983b795018c0aa2457b065507416564 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -206,7 +206,6 @@ enum node_stat_item {
> NR_FILE_PAGES,
> NR_FILE_DIRTY,
> NR_WRITEBACK,
> - NR_WRITEBACK_TEMP, /* Writeback using temporary buffers */
> NR_SHMEM, /* shmem pages (included tmpfs/GEM pages) */
> NR_SHMEM_THPS,
> NR_SHMEM_PMDMAPPED,
> diff --git a/mm/show_mem.c b/mm/show_mem.c
> index 0cf8bf5d832d6b339b4c9a6c7b8b3ab41683bcfe..41999e94a56d623726ea92f3f38785e8b218afe5 100644
> --- a/mm/show_mem.c
> +++ b/mm/show_mem.c
> @@ -246,7 +246,6 @@ static void show_free_areas(unsigned int filter, nodemask_t *nodemask, int max_z
> " shmem_pmdmapped:%lukB"
> " anon_thp:%lukB"
> #endif
> - " writeback_tmp:%lukB"
> " kernel_stack:%lukB"
> #ifdef CONFIG_SHADOW_CALL_STACK
> " shadow_call_stack:%lukB"
> @@ -273,7 +272,6 @@ static void show_free_areas(unsigned int filter, nodemask_t *nodemask, int max_z
> K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
> K(node_page_state(pgdat, NR_ANON_THPS)),
> #endif
> - K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
> node_page_state(pgdat, NR_KERNEL_STACK_KB),
> #ifdef CONFIG_SHADOW_CALL_STACK
> node_page_state(pgdat, NR_KERNEL_SCS_KB),
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index c3114b8826e4c3b6969fd4af4b0cd32173c42d7b..e0fcd9057f344170b2dc5c82beafea4ec18359bb 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1251,7 +1251,6 @@ const char * const vmstat_text[] = {
> [I(NR_FILE_PAGES)] = "nr_file_pages",
> [I(NR_FILE_DIRTY)] = "nr_dirty",
> [I(NR_WRITEBACK)] = "nr_writeback",
> - [I(NR_WRITEBACK_TEMP)] = "nr_writeback_temp",
> [I(NR_SHMEM)] = "nr_shmem",
> [I(NR_SHMEM_THPS)] = "nr_shmem_hugepages",
> [I(NR_SHMEM_PMDMAPPED)] = "nr_shmem_pmdmapped",
>
> ---
> base-commit: 4216fd45fc9156da0ee33fcb25cc0a5265049e32
> change-id: 20250625-nr_writeback_removal-4eca139cf09a
>
> Best regards,
> --
> Vlastimil Babka <vbabka@suse.cz>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter
2025-06-25 21:38 ` Joanne Koong
@ 2025-06-26 7:00 ` Jan Kara
2025-06-30 4:02 ` Miklos Szeredi
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kara @ 2025-06-26 7:00 UTC (permalink / raw)
To: Joanne Koong
Cc: Vlastimil Babka, Andrew Morton, Matthew Wilcox (Oracle),
Tejun Heo, Maxim Patlasov, Jan Kara, Zach O'Keefe,
Jonathan Corbet, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Suren Baghdasaryan, Michal Hocko,
Kirill A. Shutemov, Brendan Jackman, Johannes Weiner, Zi Yan,
Jingbo Xu, Jeff Layton, Miklos Szeredi, linux-kernel,
linux-fsdevel, linux-doc, linux-mm, Jens Axboe
On Wed 25-06-25 14:38:01, Joanne Koong wrote:
> On Wed, Jun 25, 2025 at 8:51 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > The only user of the counter (FUSE) was removed in commit 0c58a97f919c
> > ("fuse: remove tmp folio for writebacks and internal rb tree") so follow
> > the established pattern of removing the counter and hardcoding 0 in
> > meminfo output, as done recently with NR_BOUNCE. Update documentation
> > for procfs, including for the value for Bounce that was missed when
> > removing its counter.
> >
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > ---
> > The removal of the counter is straightforward. The reason for the large
> > Cc list is that there is a comment in mm/page-writeback.c function
> > wb_position_ratio() that mentions NR_WRITEBACK_TEMP, and just deleting
> > the sentence feels to me it could be the wrong thing to do - maybe the
> > strictlimit feature itself is now obsolete? It sure does mention FUSE
> > as the main reason to exist, but commit 5a53748568f79 that introduced it
> > also mentions slow USB sticks as a possibile scenario. Has that
> > happened? I'm not familiar enough with this so I'd rather highlight this
> > and ask for input here than make "git grep NR_WRITEBACK_TEMP" return
> > nothing.
>
> My understanding is that even without the fuse use case, strictlimit
> is still used for other devices via the /sys/class/bdi interface (eg
> /sys/class/bdi/<bdi>/strict_limit) so I don't think the feature itself
> is obsolete.
>
> It's not clear to me whether fuse still needs strictlimit now that it
> doesn't have tmp writeback pages, but it'd be great to get an answer
> to this, as strictlimit currently leads to too much dirty throttling
> when large folios are enabled in fuse.
Well, Miklos would be the definitive source of truth here but as far as I
know strictlimit is still desirable for FUSE even without
NR_WRITEBACK_TEMP. Otherwise dirty pages in mappings where writeback can be
potentially very slow (and definitely under userspace control) could
consume most of the global dirty limit which is not what you usually want.
That being said I can definitely see there are usecases of FUSE mounts
where you don't want this extra throttling. But then it's upto sysadmin to
configure min/max_ratio properly in these cases to avoid excessive
throttling.
Regarding the comment, I'm frankly not certain how strictlimit solved
NR_WRITEBACK_TEMP issue because NR_WRITEBACK_TEMP was never included in any
computations there AFAICS. It just helped to limit amount of outstanding
dirty pages for FUSE mappings and thus indirectly limited the scope of
NR_WRITEBACK_TEMP issue. Anyway I think the sentence is obsolete now and
deleting it is indeed the right solution because FUSE writeback is now
properly accounted in the dirty limit.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter
2025-06-26 7:00 ` Jan Kara
@ 2025-06-30 4:02 ` Miklos Szeredi
0 siblings, 0 replies; 5+ messages in thread
From: Miklos Szeredi @ 2025-06-30 4:02 UTC (permalink / raw)
To: Jan Kara
Cc: Joanne Koong, Vlastimil Babka, Andrew Morton,
Matthew Wilcox (Oracle), Tejun Heo, Maxim Patlasov,
Zach O'Keefe, Jonathan Corbet, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Suren Baghdasaryan,
Michal Hocko, Kirill A. Shutemov, Brendan Jackman,
Johannes Weiner, Zi Yan, Jingbo Xu, Jeff Layton, Miklos Szeredi,
linux-kernel, linux-fsdevel, linux-doc, linux-mm, Jens Axboe
On Thu, 26 Jun 2025 at 09:01, Jan Kara <jack@suse.cz> wrote:
> Regarding the comment, I'm frankly not certain how strictlimit solved
> NR_WRITEBACK_TEMP issue because NR_WRITEBACK_TEMP was never included in any
> computations there AFAICS. It just helped to limit amount of outstanding
> dirty pages for FUSE mappings and thus indirectly limited the scope of
> NR_WRITEBACK_TEMP issue. Anyway I think the sentence is obsolete now and
> deleting it is indeed the right solution because FUSE writeback is now
> properly accounted in the dirty limit.
The question is how much fuse can overrun the dirty limit without strictlimit.
AFAIU the strictlimit feature was added because temp pages were not
accounted as "dirty" as opposed to writeback pages which were.
Header of commit 5a53748568f7 ("mm/page-writeback.c: add strictlimit
feature") has more details. But I don't fully understand all of that,
and strictlimit may still be useful.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter
2025-06-25 15:51 [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter Vlastimil Babka
2025-06-25 21:38 ` Joanne Koong
@ 2025-07-07 14:14 ` Vlastimil Babka
1 sibling, 0 replies; 5+ messages in thread
From: Vlastimil Babka @ 2025-07-07 14:14 UTC (permalink / raw)
To: Andrew Morton, Matthew Wilcox (Oracle)
Cc: Tejun Heo, Maxim Patlasov, Jan Kara, Zach O'Keefe,
Jonathan Corbet, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Suren Baghdasaryan, Michal Hocko,
Kirill A. Shutemov, Brendan Jackman, Johannes Weiner, Zi Yan,
Joanne Koong, Jingbo Xu, Jeff Layton, Miklos Szeredi,
linux-kernel, linux-fsdevel, linux-doc, linux-mm, Jens Axboe
On 6/25/25 17:51, Vlastimil Babka wrote:
> The only user of the counter (FUSE) was removed in commit 0c58a97f919c
> ("fuse: remove tmp folio for writebacks and internal rb tree") so follow
> the established pattern of removing the counter and hardcoding 0 in
> meminfo output, as done recently with NR_BOUNCE. Update documentation
> for procfs, including for the value for Bounce that was missed when
> removing its counter.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> The removal of the counter is straightforward. The reason for the large
> Cc list is that there is a comment in mm/page-writeback.c function
> wb_position_ratio() that mentions NR_WRITEBACK_TEMP, and just deleting
> the sentence feels to me it could be the wrong thing to do - maybe the
> strictlimit feature itself is now obsolete? It sure does mention FUSE
> as the main reason to exist, but commit 5a53748568f79 that introduced it
> also mentions slow USB sticks as a possibile scenario. Has that
> happened? I'm not familiar enough with this so I'd rather highlight this
> and ask for input here than make "git grep NR_WRITEBACK_TEMP" return
> nothing.
Thanks all for the input. Andrew, please squash in this fixup. The changelog
of that can be appended to the changelog of the original patch. Thanks.
----8<----
From 55d9070995010991abc0c6dbd68a8a53b5d622bc Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Mon, 7 Jul 2025 16:09:31 +0200
Subject: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item
counter-fix
Also remove the mention of NR_WRITEBACK_TEMP implications from a comment
in wb_position_ratio(). The rest of the comment there about fuse setting
bdi->max_ratio to 1% is still correct.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/page-writeback.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 72b0ff0d4bae..3e248d1c3969 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1101,9 +1101,7 @@ static void wb_position_ratio(struct dirty_throttle_control *dtc)
* such filesystems balance_dirty_pages always checks wb counters
* against wb limits. Even if global "nr_dirty" is under "freerun".
* This is especially important for fuse which sets bdi->max_ratio to
- * 1% by default. Without strictlimit feature, fuse writeback may
- * consume arbitrary amount of RAM because it is accounted in
- * NR_WRITEBACK_TEMP which is not involved in calculating "nr_dirty".
+ * 1% by default.
*
* Here, in wb_position_ratio(), we calculate pos_ratio based on
* two values: wb_dirty and wb_thresh. Let's consider an example:
--
2.50.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-07-07 14:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-25 15:51 [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item counter Vlastimil Babka
2025-06-25 21:38 ` Joanne Koong
2025-06-26 7:00 ` Jan Kara
2025-06-30 4:02 ` Miklos Szeredi
2025-07-07 14:14 ` Vlastimil Babka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).