Date: Mon, 30 Apr 2001 11:00:37 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <200104301800.f3UI0bk41212@earth.backplane.com> References: <20010427042619.W18676@fw.wintelcom.net> <200104271757.f3RHvDW09866@earth.backplane.com> <20010427124743.E18676@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Yes, this is what I was going for, the points you made above really
:clarify a lot of things, I had the general idea that this is how
:things worked but wasn't sure about several more points, perhaps
:you have the time to answer:
:
:When do vm related changes propogate to struct buf?
The propogation can go in either direction but generally speaking you
only have to worry about buffer cache manipulation propogating to the
VM system.
A buffer cache buffer (struct buf) may exist with or without its
backing store attached. If the backing store is attached then the
underlying VM pages are wired. If the backing store is not attached
then the underlying VM pages are independant of the buffer.
The buffer cache attaches and detaches backing store regularly, and
much of the complexity of the buffer cache revolves around edge cases
that occur due to this activity. For example, if the buffer cache
detaches its backing store the paging system may then piecemeal-free
the underlying pages. When the buffer cache re-attaches the backing
store there may be missing pages which it must then allocate, attach,
and issue I/O on. The wiring of the backing store is *NOT* a lock
on the backing VM pages but does prevent them from being freed out
from under you.
VM pages have two notions of 'busy'. There is PG_BUSY, which is a
real honest to god lock on a VM page, and there is m->busy, which
is a 'soft busy' hold on the page during I/O. You will not be able
to convert either of these notions into a mutex - definitely do not
try to add a mutex to the vm_page structure itself.
: Can is happen at interrupt time?
: Is it done when asking for access/lock to a buf? (that would be ideal)
: Or will I need to do locking under vfs_bio to make sure that
: b->b_flags and b->b_pages are in sync wrt to vm?
:
:I am going for that giant vm lock. I've also removed the atomic ops
:from vm_object and vm_page flags/refcounting. My guess is that this
:may gain us some performance, but I'll have to see, right now anything
:is better than giant and so far some cool stuff runs without the Giant
:lock:
I think a VM object mutex you can safely remove the atomic ops
from vm_object, but I don't think you can safely remove the atomic ops
from vm_page unless you intend to disable interrupts permanently
(or as a permanent side effect of mutex operation) for the duration
of any VM operation.
Most of the vm_page related code already assumes interrupt preemption
and should mostly work with SMP, perhaps with just a few tweaks.
: obreak getpagesize sbrk sstk mmap ovadvise munmap mprotect madvise
: mincore mmap mlock munlock minherit msync mlockall munlockall
:
:and..
:
: vm_fault
:
:Using a combination of your and Doug Ambrisko's diskless stuff as
:well a dusty old p100 I've got a box here that boots in under 20
:seconds, really makes the compile/test cycle amazingly tolerable.
:
:--
:-Alfred Perlstein - [alfred@freebsd.org]
:http://www.egr.unlv.edu/~slumos/on-netbsd.html
That sounds like good progress to me.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104301800.f3UI0bk41212>