Date: Fri, 27 Apr 2001 10:57:13 -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: <200104271757.f3RHvDW09866@earth.backplane.com> References: <20010427042619.W18676@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:If you're booting diskless you get to mounting/using the md0 disk :and you panic because I haven't made ufs_readwrite safe. : :http://people.freebsd.org/~alfred/vm.diff : :I'm having fun but a bit concerned, I have a lot of places where :locks are "optional", meaning that callers can have a lock or not :mostly depending on if the function being called will block or not. : :Getting into UFS is starting to get somewhat hairy as there seems :like there's going to be a lock of lock/unlock or places where the :lock is held for a long period. : :Anyhow, if you want to check it out, comment on what's going on :with it, let me know. If you'd like to take a subsystem and work :out how to vm safe it let me know. Just let me know, ok? :) : :-- :-Alfred Perlstein - [alfred@freebsd.org] 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. -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?200104271757.f3RHvDW09866>