Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/raidframe



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



Home | Main Index | Thread Index | Old Index