Date: Thu, 25 Feb 1999 15:18:12 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: dillon@apollo.backplane.com Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, luoqi@watermarkgroup.com, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Message-ID: <199902252018.PAA00939@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> I noticed that too, but it wasn't the cause of my lockup. If I understand > the buffer cache, other entities use the buffer KVA space too, not just > the primary buffer cache. There is also the getpbuf() pool. > P-bufs get their kva from pager_map, seperate from regular bufs which use buffer_map. I did a global search for "buffer_map", and it turned out it's only used by getnewbuf() to allocate buffer kva space, so I'm pretty sure buffer_map is under utilized. > Of course, the syncer may indirectly call getnewbuf() as well, which is > why getnewbuf() needs to be able to allocate out of an emergency reserve > ( < lonumfreebuffers ) - in order to guarentee that if it *does* block, > there are enough writes in progress to clear out some more free buffers. > Yes, this is what I meant. I was a little mistaken though, I was worried this recursion might cause syncer's stack to overflow, but this would not happen, because syncer can tap into the emergency reserve, therefore there won't be a cascade of writes of totally irrelevent bufs. > The same emergency reserve must be implemented for KVA space, for the same > reason. These 'emergecy reserves' are really just comparisons against > summary counters, aka 'numfreebuffers' and 'kvafreespace'. > Agreed. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902252018.PAA00939>