Date: Tue, 12 Sep 1995 13:42:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Cc: terry@lambert.org, current@FreeBSD.org Subject: Re: Statistics request Message-ID: <199509122042.NAA02216@phaeton.artisoft.com> In-Reply-To: <199509121919.MAA04151@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 12, 95 12:19:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Those are just spot selecting the non-0 ones... > > Now fire up 3 copies of find: > namei 2 1K 6K 8873K 168480 0 0 16,32,64,1K > namei 2 1K 6K 8873K 172299 0 0 16,32,64,1K > namei 1 1K 6K 8873K 172415 0 0 16,32,64,1K The question is whether it self-zero's. If it does, then care has been taken to doubly-break the buffer allocation code in nfs_namei(), which is what I'm trying to determine. I would expect that if this were the case, it would re-zero when idle. If it is only singly broken, I'd expect the number of buffers to increase and keep increasing, or to start freeing stuff that isn't allocated. I haven't determined what statistic free unallocated buffers would bump; unfortunately, I think it would be hidden in the noise on anything that could reproduce the error cases. Garrett has reported 0's in the idle case on his box. I will probably need to write some shell test cases to specifically exercise the bogus code. Anyone have any idea what statistic will show preterbation when I free a buffer twice? I'd like to watch that one too. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509122042.NAA02216>