Date: Wed, 13 Dec 2000 02:49:55 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Seigo Tanimura <tanimura@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org, cp@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vfsops.c Message-ID: <20001213024954.B16205@fw.wintelcom.net> In-Reply-To: <200012131003.eBDA3rh34394@freefall.freebsd.org>; from tanimura@FreeBSD.org on Wed, Dec 13, 2000 at 02:03:53AM -0800 References: <200012131003.eBDA3rh34394@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Seigo Tanimura <tanimura@FreeBSD.org> [001213 02:04] wrote: > tanimura 2000/12/13 02:03:53 PST > > Modified files: > sys/ufs/ffs ffs_vfsops.c > Log: > Do not race for the lock of an inode hash. I don't understand why there just isn't a single mutex here. ffs_ihash_lock is really a mutex that depends on mutual exclusion of the pre-SMPng kernel to work properly. Why wasn't ffs_ihash_lock turned into a mutex and everything hinged off of that, instead of having a seperate lock over another lock that's just there for mutual exclusion. I see that BSD/os does the same thing. Can anyone explain this strangeness to me without just quoting "we don't sleep on locks" This adds a bunch of overhead for what looks like no apparent reason. You realize that: Finding a process on a wakeup hash is probably more expensive than waking up a process hung off a mutex because you don't have to look very far? Is that true? If not why not? That there are two extra mutex calls because of this? That maybe the code should be using wakeup_one() as well? I'm not sure how wakeup_one works with respect to FIFO or LIFO, if it's LIFO then this can cause problems because of lots of processes wedged on this getting stuck behind the newcomers. If it's FIFO we should be fine. The only three things I can think of is that: 1) this is done to preserve priority, but they all sleep at PVM so it doesn't matter. 2) this is done to preserve interruption by a signal. (but this code doesn't give PCATCH to tsleep() so that is not applicable here). 3) this will be replaced with a conditional variable at some point to speed the wakeup(). thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001213024954.B16205>