From owner-freebsd-current Sun Oct 24 19:50:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BD6FD1516A for ; Sun, 24 Oct 1999 19:50:45 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA70038; Sun, 24 Oct 1999 19:49:36 -0700 (PDT) (envelope-from dillon) Date: Sun, 24 Oct 1999 19:49:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199910250249.TAA70038@apollo.backplane.com> To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG Subject: Re: Deadlock in nbufkv References: <99Oct25.071534est.40323@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've recently upgraded a system from 3.2-RELEASE to -CURRENT as of :30-Sept (just before the signal changes). I now find that when :I try to do a CVS checkout, the system hangs, with cvs in `nbufkv'. : :The CVSROOT is on a filesystem with standard 8K/1K blocks. The :target FS is 32k/4k. Both FS are running softupdates. This worked :without problem under 3.2. The kernel config files are basically :the same (modulo config(8) changes). FWIW, it has 'maxusers 5' :and no other options over-riding default kernel memory sizes. : :I notice that Matt Dillon found his FS stress program also hung in :nbufkv, but that was with 64k blocks. Other than that, I can't :find any reference to nbufkv here, in the PR list or in the sys :commitlogs. : :Does anyone have any ideas? Should I just go back to 8K/1K blocks? : :Peter For production you should definitely go back to 8K/1K blocks. If you want to help track down the sleep/wakeup problem causing the nbufkv lockup you should leave them at 32K or higher. I just recently committed a couple of changes that should fix some of the nbufkv lockups. There are probably still some holes I haven't plugged. Essentially what occurs is that the larger block size exercises a portion of the buffer cache not usually exercised -- the KVM defragmentation code, and there are instances where processes sleep waiting for buffer cache KVM (nbufkv) but never get woken up again. :-- :Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au :Alcatel Australia Limited :41 Mandible St Phone: +61 2 9690 5019 :ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message