On Fri, Jan 23, 2004 at 01:57:08AM +0000, Greg Oster wrote: > > Module Name: src > Committed By: oster > Date: Fri Jan 23 01:57:08 UTC 2004 > > Modified Files: > src/sys/dev/raidframe: rf_stripelocks.c > > Log Message: > Always ask for a new RF_StripeLockDesc_t "just in case", and then > give it back if we don't need it. If we don't allocate it before > we take our lock, LOCKDEBUG (rightfully) complains that we're trying > to grab something from the pool with PR_WAITOK. This code (and the > PR_WAITOK in particular) really needs to be revisited at some point. How often do we go through this path? Would it make sense to have a global single cache? Have a simplelock and a global RF_StripeLockDesc_t *. On entry, if there's one in the cache, take it. Otherwise do the allocation you have now. Do what you do now. Then grab the cache lock. If there's not one in the cache, put this one in. Otherwise, free it. I think the cache lock twiddling and comparison against NULL would be less work than the memory allocation. :-) This kind of change would trade off usually having one RF_StripeLockDesc_t lying around for not having to allocate then deallocate it each pass. With __predict_true() and __predict_false() (are those the names?), the code can be efficient in the common case. You're the only one, though, who knows if it'd be worth it. :-) Take care, Bill
Attachment:
pgpPSexzfB8vr.pgp
Description: PGP signature