Date: Sun, 24 Oct 1999 19:49:36 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Deadlock in nbufkv Message-ID: <199910250249.TAA70038@apollo.backplane.com> References: <99Oct25.071534est.40323@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910250249.TAA70038>