From owner-freebsd-arch Thu Jan 23 18:10: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACF1F37B401; Thu, 23 Jan 2003 18:10:00 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 296EA43EB2; Thu, 23 Jan 2003 18:10:00 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0463.cvx22-bradley.dialup.earthlink.net ([209.179.199.208] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18btHu-00046q-00; Thu, 23 Jan 2003 18:09:47 -0800 Message-ID: <3E309FE5.F74564DC@mindspring.com> Date: Thu, 23 Jan 2003 18:07:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: John Baldwin , arch@FreeBSD.org, Andrew Gallatin Subject: Re: M_ flags summary. References: <1043339738.29341.1.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ac06470c581d13d67968bfa9f4b6c0d5a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Thu, 2003-01-23 at 15:39, John Baldwin wrote: > > This would prevent the malloc implementation from using internal mutexes > > that it msleep's or cv_wait's on. You only get to pass in one mutex > > to cv_wait* and msleep. > > That did occur to me too, which was why I wrote "or something". It looks > hard to DTRT here without a version of msleep which took a list of > mutexes to release. The hard part here is that this is almost entirely useless for most FS directory operations, which must hold both the mutex for the parent directory, and the mutex for the object being manipulated, plus potentially other mutexes (e.g. rename), etc.. There are other places where this is true, too. > > In my experience, one can often "fix" problems > > with holding locks across malloc() by malloc()'ing things earlier in the > > function before you need locks. > > This is obviously preferable. This is preferrable for *most* cases. For cases where a failure of an operation to complete immediately results in the operation being queued, which requires an allocation, then you are doing a preallocation for the failure code path. Doing a preallocation that way is incredibly expensive. If on the other hand, you are doing the allocation on the assumption of success, then it's "free". The real question is whether or not the allocation is in the common or uncommon code path. The easy way to mitigate the issue here is to maintain an object free list, and use that, instead of the allocator. Of course, if you do that, you can often avoid holding a mutex altogether. And if the code tolerates a failure to allocate reasonably well, you can signal a "need to refill free list", and not hold a mutex over an allocation at all. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message