Date: Thu, 23 Jan 2003 18:07:33 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Doug Rabson <dfr@nlsystems.com> Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: M_ flags summary. Message-ID: <3E309FE5.F74564DC@mindspring.com> References: <XFMail.20030123103959.jhb@FreeBSD.org> <1043339738.29341.1.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E309FE5.F74564DC>