RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry accounting
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 23 Oct 2024 17:28:14 UTC
Mark Johnston <markj_at_FreeBSD.org> wrote on Date: Tue, 22 Oct 2024 12:50:42 UTC : > The branch main has been updated by markj: > > URL: https://cgit.FreeBSD.org/src/commit/?id=6a07e67fb7a8b5687a492d9d70a10651d5933ff5 > > commit 6a07e67fb7a8b5687a492d9d70a10651d5933ff5 > Author: Mark Johnston <markj@FreeBSD.org> > AuthorDate: 2024-10-22 12:48:43 +0000 > Commit: Mark Johnston <markj@FreeBSD.org> > CommitDate: 2024-10-22 12:48:43 +0000 > > vm_meter: Fix laundry accounting > > Pages in PQ_UNSWAPPABLE should be considered part of the laundry. > Otherwise, on systems with no swap, the total amount of memory visible > to tools like top(1) decreases. > > It doesn't seem very useful to have a dedicated counter for unswappable > pages, and updating applications accordingly would be painful, so just > lump them in with laundry for now. > > PR: 280846 > Reviewed by: bnovkov, kib > MFC after: 1 week > Differential Revision: https://reviews.freebsd.org/D47216 > --- > sys/vm/vm_meter.c | 20 +++++++++++++++++--- > 1 file changed, 17 insertions(+), 3 deletions(-) > > diff --git a/sys/vm/vm_meter.c b/sys/vm/vm_meter.c > index faf4074ef0c6..fef28bb883e4 100644 > --- a/sys/vm/vm_meter.c > +++ b/sys/vm/vm_meter.c > @@ -455,7 +455,8 @@ u_int > vm_laundry_count(void) > { > > - return (vm_pagequeue_count(PQ_LAUNDRY)); > + return (vm_pagequeue_count(PQ_LAUNDRY) + > + vm_pagequeue_count(PQ_UNSWAPPABLE)); > } > > static int > @@ -477,6 +478,18 @@ SYSCTL_PROC(_vm_stats_vm, OID_AUTO, v_pdpages, > CTLTYPE_U64 | CTLFLAG_MPSAFE | CTLFLAG_RD, NULL, 0, sysctl_vm_pdpages, "QU", > "Pages analyzed by pagedaemon"); > > +static int > +sysctl_vm_laundry_pages(SYSCTL_HANDLER_ARGS) > +{ > + struct vm_domain *vmd; > + u_int ret; > + > + vmd = arg1; > + ret = vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt + > + vmd->vmd_pagequeues[PQ_UNSWAPPABLE].pq_cnt; > + return (SYSCTL_OUT(req, &ret, sizeof(ret))); > +} > + > static void > vm_domain_stats_init(struct vm_domain *vmd, struct sysctl_oid *parent) > { > @@ -503,8 +516,9 @@ vm_domain_stats_init(struct vm_domain *vmd, struct sysctl_oid *parent) > "inactpdpgs", CTLFLAG_RD, > &vmd->vmd_pagequeues[PQ_INACTIVE].pq_pdpages, 0, > "Inactive pages scanned by the page daemon"); > - SYSCTL_ADD_UINT(NULL, SYSCTL_CHILDREN(oid), OID_AUTO, > - "laundry", CTLFLAG_RD, &vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt, 0, > + SYSCTL_ADD_PROC(NULL, SYSCTL_CHILDREN(oid), OID_AUTO, > + "laundry", CTLFLAG_RD | CTLTYPE_UINT, vmd, 0, > + sysctl_vm_laundry_pages, "IU", > "laundry pages"); > SYSCTL_ADD_U64(NULL, SYSCTL_CHILDREN(oid), OID_AUTO, > "laundpdpgs", CTLFLAG_RD, I see that there are 4 laundry-related (Unswappable included) per vm.domian.* (my context only has domain 0, so that is what I show): vm.domain.0.stats.laundpdpgs: Laundry pages scanned by the page daemon vm.domain.0.stats.laundry: laundry pages vm.domain.0.stats.unswappable: Unswappable pages vm.domain.0.stats.unswppdpgs: Unswappable pages scanned by the page daemon Also, there is: vm.stats.vm.v_laundry_count: Pages eligible for laundering (vm.stats.vm.* seems to have nothing analogous to unswappable) (Unswappable is being treated as laundry in some places to avoid under accounting for the total memory spanned.) It seems that the descriptions should now likely be explicit about the context each covers, one of: ) Swappable Laundry ) Unswappable Laundry ) Swappable+Unswappable Laundry In part, this would guide figuring out when to add vs. substract vs. use-as-is for what one wants to produce from the information. Where ever Swappable+Unswappable in old calling-code may be in use, those arithmetic operations would now double count Unswappable. (I've no clue if there is such code someplace.) My notes in the PR about this may have the details wrong about which changed vs. which did not: I only just noticed the vm.stats.vm.v_laundry_count was something that I'd missed so I'd thought there was only one laundry place and did not check which at the time. So my details there should not be followed but just be considered as suggestive types of wording that might be involved. === Mark Millard marklmi at yahoo.com