Date: Fri, 27 Apr 2001 12:47:43 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: smp@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <20010427124743.E18676@fw.wintelcom.net> In-Reply-To: <200104271757.f3RHvDW09866@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Apr 27, 2001 at 10:57:13AM -0700 References: <20010427042619.W18676@fw.wintelcom.net> <200104271757.f3RHvDW09866@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010427 10:57] wrote: > > There are about fifty thousand places where the VM system assumes a > contextual lock. Basically what it comes down to is: > > * VM Pages cannot be busied from an interrupt, but can be unbusied > > * VM Objects cannot be manipulated from an interrupt > > * Mainline kernel code assumes type-stability for VM pages (easy) > > * Mainline kernel code assumes that if it looks a VM page up and the > page is not busy, that it can busy it without any locking (since > interrupts cannot busy new pages, only unbusy them). > > * Mainline kernel code assumes that it can manipulate VM objects without > any locking if it does not block. > > The only place where we have 'real' locking in regards to supporting SMP > under -stable are VM maps. i.e. the vm_map_lock() stuff existed in > -stable originally to help out with kmap locking (since interrupts could > manipulate kmap's), and was extended to support SMP in -stable due to > the fact that VM maps could be shared amoungst rforked processes. > > Unfortunately, there is no yardstick to determine where you need VM > locking -- the splvm() stuff in stable is only there for interrupt > interlocks, not for process<->process interlocks, so you can't simply > put a mutex in where splvm() was before. > > Under -current you are going to have to wind up using what will > effectively be a giant lock for the VM system. I recommend starting > with that and making sure you have a stable -current system, then > you can start moving the locks inward. I do not recommend trying to > immediately implement a mutex on major VM structures (like VM objects)... > you are almost guarenteed to create dozens of deadlock situations. Make > it work first, then start implementing the finer-grained locks. 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? 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: 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 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?20010427124743.E18676>