:ok
:
: hadn't seen this one when I sent the previous email..
:
:Julian
:
:
:On Mon, 28 Jun 1999, Matthew Dillon wrote:
:
:> :You are right that the buffer cache is very tricky. It is hard to
:> :change it in ways that preserves functionality and performance.
:...
I've had a long phone conversation with Kirk. We're basically on the
same page. The concentration has got to be to stabilize what we have
first, and we will worry about formalizing (and cleaning up) the lock
semantics later.
Basically what it comes down to is that the exclusive locks on struct
buf's are going to have to move to an always-recursive model to handle
certain situations that come up both with softupdates and with VFS
layering. The original B_BUSY locks were exclusive but non-recursive.
The differences between recursive and non-recursive exclusive locks
plus unexpected side effects from lockmgr() operation are what led to
the bugs in the original commit. For example, recursive exclusive locks
require ownership reassignment while non-recursive exclusive locks do
not. This led to the KERNPROC hack, and is why it needs to stay in
at least until we can formalize the lock semantics and find a choke point
(maybe involving fiddling with b_flags) to implement the case more
appropriately.
I think I also have a good line on how to finally fix the
blocking-during-write-I/O problem. Basically it involves taking
a page out of UVM and making VMIO pages copy-on-write for the purposes
of an I/O, allowing the write operation to take out a shared lock on
the buffer instead of an exclusive lock. The I/O operation gets the
real page, and if the system needs to write to it while the I/O is in
progress the system allocates and copies the page on the fly and the
page being used for the I/O is detached (and freed at the end of the I/O).
We would essentially get rid of the bogus page junk and replace it with
copy-on-write junk.
Kirk and I both think that we can get rid of nearly all the blocking
conditions that occur during an access to a buffer that is simultanious
with an I/O being performed on the same buffer.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
