Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Growth in pool usage between netbsd-9 and -10?



On Sat, Sep 09, 2023 at 10:17:56PM +0000, Andrew Doran wrote:
> On Fri, Sep 08, 2023 at 12:27:57PM +1000, Paul Ripke wrote:
> 
> > I need to read more code to see when the pools decide to release idle
> > pages - because this is remarkably wasteful considering my machine is
> > also paging, and "only" has 16GiB RAM.
> > 
> > Memory resource pool statistics
> > Name        Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
> > buf2k       2048   830780    0   617706 207284 85623 121661 172466  0   inf 6948
> > vcachepl     640 44075984    0 43266390 5228141 5012754 215387 704585 0 inf 3547
> > pcgnormal    320 23415927 32666190 23388721 1050250 1045247 5003 89205 0 inf 2425
> > ffsdino2     264 43386098    0 42621716 1690136 1577576 112560 281810 0 inf 2185
> > ffsino       280 43312409    0 42548027 1850682 1733882 116800 301939 0 inf 2143
> > ractx         40  6888877    0  6846710 41237 37592  3645  4679     0   inf 1780
> > bufpl        280   557611    0   239663 31776   559 31217 31296     0   inf 1362
> > buf16k      16896  431232    0   350158 52798 21935 30863 32706     0   inf  942
> > mclpl       2048   120600    0   119876 32540 31337  1203  5270     0 261333 841
> > pvpage      4096    61134    3    53585 40271 32334  7937 12454     0   inf  388
> > mbpl         520   205550    0   204337 13673 12993   680  3049     0   inf  362
> > pcglarge    1088   844473    0   825312 88124 81378  6746  9809     0   inf  359
> > buf4k       4096    28406    0    25833  5510  2654  2856  4001     0   inf  283
> > ...
> > Totals           1937415183 32666228 1927493251 11060670 10142826 917844
> > 
> > In use 3585418K, total allocated 5569236K; utilization 64.4%
> 
> The targets are roughly 10% of RAM for vnodes and 15% for bufcache which
> adds up to 25%.  So this doesn't seem so totally off the mark.  DIAGNOSTIC
> does add a bit of overhead since it messes up all the kmem cache sizes with
> debugging stuff.

Ah, DIAGNOSTIC! I haven't looked into it's implementation, and hadn't realized
it messes with this. I see a couple of my systems with DIAGNOSTIC have the
unusual patterns.

> I have plans to reduce the overhead from vnodes but not enough to claw back
> 100s of MB..  Sometimes I think the method for sizing these caches should be
> non-linear or something - don't have a good idea yet.

Yeah, caches are hard. Memory management is hard. I see this enough
at $DAYJOB.

-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.


Home | Main Index | Thread Index | Old Index