Date: Thu, 25 Feb 1999 12:23:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Luoqi Chen <luoqi@watermarkgroup.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: <199902252023.MAA08967@apollo.backplane.com> References: <199902252018.PAA00939@lor.watermarkgroup.com>
next in thread | previous 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.
Ah, ok... that is very easy to fix but I would ask anyone who is testing
my patch to *NOT* fix the maxbufspace initialization. Having it
artificially low will exercise the buffer cache more. The code needs to
be robust enough to survive extreme usage on a small buffer cache.
We'll fix it when we commit the final patch.
:> 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.
Right, plus it will block if the emergency reserve runs out. I'm not
100% sure that is safe, but I think it should be .. there should be enough
in-transit I/O already in progress so buffers/kva-space free up even
when the syncer is blocked.
:> 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
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902252023.MAA08967>