From owner-freebsd-hackers Thu Feb 25 12:24: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id ADD5615097 for ; Thu, 25 Feb 1999 12:23:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA08967; Thu, 25 Feb 1999 12:23:38 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Feb 1999 12:23:38 -0800 (PST) From: Matthew Dillon Message-Id: <199902252023.MAA08967@apollo.backplane.com> To: Luoqi Chen 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 References: <199902252018.PAA00939@lor.watermarkgroup.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message