Date: Sun, 27 Jun 1999 10:32:21 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: current@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: BUF_LOCK() related panic.. Message-ID: <199906271732.KAA14208@apollo.backplane.com> References: <19990627084414.24D4D81@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:It seems to me the main problem (so far) is the buftimelock..
:
: simple_lock(&buftimelock);
: bp->b_lock.lk_wmesg = buf_wmesg;
: bp->b_lock.lk_prio = PRIBIO + 4;
: bp->b_lock.lk_timo = 0;
: return (lockmgr(&(bp)->b_lock, locktype, &buftimelock, curproc));
:
:Inside lockmgr():
:
: simple_lock(&lkp->lk_interlock);
: if (flags & LK_INTERLOCK)
: simple_unlock(interlkp);
: ^^^^^^^^ <--- &buftimelock;
:
:Note that there is no LK_INTERLOCK in any of the calls to lockmgr().. On
:UP, simplelocks are noops. On SMP, they are real and nothing is ever
:freeing buftimelock.
Ah ha! That is definitely one problem. It may be the interim fix I've
been looking for.
:But that doesn't fix the UP problem where cluster_wbuild() tries to
:recursively re-lock a buf that the current process already owns. I have a
:few ideas about that one though, I just don't understand the clustering
:well enough yet to fix it.
I haven't had any problems with cluster_wbuild(), are you sure?
It looks ok to me.
:Speaking of SMP and simple locks, I'd like to turn on the debugging
:simplelocks that keep a reference count and check before switching to make
:sure that a process doesn't sleep holding a lock. This is a pretty
:fundamental sanity check and would have found the LK_INTERLOCK problem
:above before it got committed.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
I think this would be a good idea.
In general, I really dislike the complexity of both simplelocks and
lockmgr locks. Simplelocks aren't as simple as they should be and
really abuse SMP principles badly if they are indeed attempting to disable
interrupts on a global scale! lockmgr() locks are so expensive that
using them anywhere represents a serious performance concern. Their use
in the buffer cache code is going to be strictly temporary because of that.
Hopefully we will be able to remove them from the VFS code as well later
this year. They are unbelievably expensive, cutting at least 15 MBytes/sec
of cache-case I/O bandwidth.
What we really need to do is get rid of all the I/O and interrupt-safety
code that is being pushed into core infrastructure routines such as
simplelocks and instead operate interrupts as kernel threads. Spinlocks
need to be split into two kinds: One that actually spins, and one that
does a thread switch in its core loop ( but does not actually try to
sleep ). Thread-switching spinlocks would replace much of the current
use for spinlocks while the true spinlocks would be used only in
non-preemptive threads ( i.e. not used for anything that interacts with
an interrupt ). It is then a simple matter to work on further separating
resource access by interrupts to reduce the number of involuntary
synchronous context switches out of an interrupt thread - a simple
performance issue rather then a system-stopping issue.
-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?199906271732.KAA14208>