mm: don't show nr_indirectly_reclaimable in /proc/vmstat
Subsystems (3)
PATCH 1/1 mm: don't show nr_indirectly_reclaimable in /proc/vmstat
Don't show nr_indirectly_reclaimable in /proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
--- mm/vmstat.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
mm/vmstat.c +5 -1
@@ -1161,7 +1161,7 @@ const char * const vmstat_text[] = {"nr_vmscan_immediate_reclaim" ,"nr_dirtied" ,"nr_written" , -"nr_indirectly_reclaimable" , +"" ,/* nr_indirectly_reclaimable */ /* enum writeback_stat_item counters */ "nr_dirty_threshold",
@@ -1740,6 +1740,10 @@ static int vmstat_show(struct seq_file *m, void *arg)unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; +/* Skip hidden vmstat items. */ +if (*vmstat_text[off] =='\0' ) +return 0 ; +seq_puts (m, vmstat_text[off]);seq_put_decimal_ull (m," " , *l);seq_putc (m,'\n' );
Signature · 1 line
2.14.3
Quoted 5 lines · Roman Gushchin
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
Oh, you beat me to it, thanks.
Quoted 7 lines
Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>
Andrew, can you send this to Linus before the current rc period ends, please?
Thanks,
Vlastimil
Quoted 29 lines
--- mm/vmstat.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)mm/vmstat.c +5
-1@@ -1161,7 +1161,7 @@ const char * const vmstat_text[] = {"nr_vmscan_immediate_reclaim" ,"nr_dirtied" ,"nr_written" , -"nr_indirectly_reclaimable" , +"" ,/* nr_indirectly_reclaimable */ /* enum writeback_stat_item counters */ "nr_dirty_threshold",@@ -1740,6 +1740,10 @@ static int vmstat_show(struct seq_file *m, void *arg)unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; +/* Skip hidden vmstat items. */ +if (*vmstat_text[off] =='\0' ) +return 0 ; +seq_puts (m, vmstat_text[off]);seq_put_decimal_ull (m," " , *l);seq_putc (m,'\n' );
Quoted 6 lines · Roman Gushchin
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
I don't think it should be a per-node vmstat, in this case. It appears only to be used for the global context. Shouldn't this be handled like totalram_pages, total_swap_pages, totalreserve_pages, etc?
Quoted 35 lines
Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>--- mm/vmstat.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)mm/vmstat.c +5
-1@@ -1161,7 +1161,7 @@ const char * const vmstat_text[] = {"nr_vmscan_immediate_reclaim" ,"nr_dirtied" ,"nr_written" , -"nr_indirectly_reclaimable" , +"" ,/* nr_indirectly_reclaimable */ /* enum writeback_stat_item counters */ "nr_dirty_threshold",@@ -1740,6 +1740,10 @@ static int vmstat_show(struct seq_file *m, void *arg)unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; +/* Skip hidden vmstat items. */ +if (*vmstat_text[off] =='\0' ) +return 0 ; +seq_puts (m, vmstat_text[off]);seq_put_decimal_ull (m," " , *l);seq_putc (m,'\n' );
Quoted 9 lines · David Rientjes
Quoted 6 lines · Roman Gushchin
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
Quoted 3 lines
I don't think it should be a per-node vmstat, in this case. It appears only to be used for the global context. Shouldn't this be handled like
totalram_pages,total_swap_pages,totalreserve_pages, etc?
Hi, David!
I don't see any reasons why re-using existing infrastructure for fast vm counters is bad, and why should we re-invent it for this case.
Thanks!
Quoted 7 lines · Roman Gushchin
Quoted 7 lines
Quoted 6 lines
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
Quoted 9 lines
Quoted 3 lines
I don't think it should be a per-node vmstat, in this case. It appears only to be used for the global context. Shouldn't this be handled like
totalram_pages,total_swap_pages,totalreserve_pages, etc?Hi, David!
I don't see any reasons why re-using existing infrastructure for fast vm counters is bad, and why should we re-invent it for this case.
Because now you have to modify the existing infrastructure for something that shouldn't be a vmstat in the first place?
Quoted 6 lines · Roman Gushchin
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.
Quoted 7 lines
Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>
This is quite a hack. I would much rather revert the counter and fixed it the way Vlastimil has proposed. But if there is a strong opposition to the revert then this is probably the simples thing to do. Therefore
Quoted 30 lines
--- mm/vmstat.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)mm/vmstat.c +5
-1@@ -1161,7 +1161,7 @@ const char * const vmstat_text[] = {"nr_vmscan_immediate_reclaim" ,"nr_dirtied" ,"nr_written" , -"nr_indirectly_reclaimable" , +"" ,/* nr_indirectly_reclaimable */ /* enum writeback_stat_item counters */ "nr_dirty_threshold",@@ -1740,6 +1740,10 @@ static int vmstat_show(struct seq_file *m, void *arg)unsigned long *l = arg;unsigned long off = l - (unsigned long *)m->private; +/* Skip hidden vmstat items. */ +if (*vmstat_text[off] =='\0' ) +return 0 ; +seq_puts (m, vmstat_text[off]);seq_put_decimal_ull (m," " , *l);seq_putc (m,'\n' );Signature · 1 line
2.14.3
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 14 lines · Michal Hocko
Quoted 6 lines
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.Quoted 7 lines
Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>
Quoted 4 lines
This is quite a hack. I would much rather revert the counter and fixed it the way Vlastimil has proposed. But if there is a strong opposition to the revert then this is probably the simples thing to do. Therefore
Implementing this counter as a vmstat doesn't make much sense based on how it's used. Do you have a link to what Vlastimil proposed? I haven't seen mention of alternative ideas.
Quoted 16 lines · David Rientjes
Quoted 14 lines · Michal Hocko
Quoted 13 lines
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>
Quoted 8 lines
Quoted 4 lines
This is quite a hack. I would much rather revert the counter and fixed it the way Vlastimil has proposed. But if there is a strong opposition to the revert then this is probably the simples thing to do. Therefore
Implementing this counter as a vmstat doesn't make much sense based on how it's used. Do you have a link to what Vlastimil proposed? I haven't seen mention of alternative ideas.
It was in the original thread, see e.g.
<[email protected]>
However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that /proc/vmstat is an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Quoted 29 lines · Vlastimil Babka
Quoted 16 lines · David Rientjes
Quoted 14 lines · Michal Hocko
Quoted 13 lines
Don't show
nr_indirectly_reclaimablein/proc/vmstat, because there is no need in exporting this vm counter to the userspace, and some changes are expected in reclaimable object accounting, which can alter this counter.Signed-off-by Roman Gushchin <[email protected]>Cc Vlastimil Babka <[email protected]>Cc Matthew Wilcox <[email protected]>Cc Andrew Morton <[email protected]>Cc Alexander Viro <[email protected]>Cc Michal Hocko <[email protected]>Cc Johannes Weiner <[email protected]>Quoted 8 lines
Quoted 4 lines
This is quite a hack. I would much rather revert the counter and fixed it the way Vlastimil has proposed. But if there is a strong opposition to the revert then this is probably the simples thing to do. Therefore
Implementing this counter as a vmstat doesn't make much sense based on how it's used. Do you have a link to what Vlastimil proposed? I haven't seen mention of alternative ideas.
It was in the original thread, see e.g.
<[email protected]>
Quoted 7 lines
However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that
/proc/vmstatis an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Thank you, Vlastimil!
That pretty much matches my understanding of the case.
BTW, are you planning to work on supporting reclaimable objects by slab allocators?
Thanks!
Quoted 18 lines · Roman Gushchin
Quoted 9 lines · Vlastimil Babka
Quoted 4 lines · David Rientjes
Implementing this counter as a vmstat doesn't make much sense based on how it's used. Do you have a link to what Vlastimil proposed? I haven't seen mention of alternative ideas.
It was in the original thread, see e.g.
<[email protected]>Quoted 7 lines
However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that
/proc/vmstatis an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Quoted 5 lines
Thank you, Vlastimil!
That pretty much matches my understanding of the case.BTW, are you planning to work on supporting reclaimable objects by slab allocators?
Yeah, soon!
Vlastimil
Quoted 6 lines
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Vlastimil Babka
It was in the original thread, see e.g.
<[email protected]>However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that
/proc/vmstatis an ABI that we can't change (i.e. counters have been presumably removed in the past already).
What prevents this from being a simple atomic_t that gets added to in __d_alloc(), subtracted from in __d_free_external_name(), and read in si_mem_available() and __vm_enough_memory()?
Quoted 13 lines · David Rientjes
Quoted 10 lines · Vlastimil Babka
It was in the original thread, see e.g.
<[email protected]>However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that
/proc/vmstatis an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Quoted 3 lines
What prevents this from being a simple
atomic_tthat gets added to in__d_alloc(), subtracted from in__d_free_external_name(), and read insi_mem_available()and__vm_enough_memory()?
I'd think you'd want one atomic_t per NUMA node at least ...
Quoted 13 lines · David Rientjes
Quoted 10 lines · Vlastimil Babka
It was in the original thread, see e.g.
<[email protected]>However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that
/proc/vmstatis an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Quoted 3 lines
What prevents this from being a simple
atomic_tthat gets added to in__d_alloc(), subtracted from in__d_free_external_name(), and read insi_mem_available()and__vm_enough_memory()?
The counter is already in mainline, so I think it's easier to simply just stop printing it now than trying to replace its implementation with one that can cause cache ping pongs.