Matthew Dillon wrote: > This is approximately what I am thinking. Note that this gives us the > flexibility to create a larger infrastructure around the bucket cache, > such as implement per-cpu caches and so on and so forth. What I have > here is the minimal implementation.
Uh, probably freeing the mutex of the new bucket after holding the one on the "next" list is probably not what you wanted to happen. 8-). I think you would nead a seperate "head", and then use the head containing structure mutex, instead. I understand what you were trying to do, though... I guess you are relying on the use of different buckets to spread the pain? Right now the pain is centered arouns one struct type anyway (the cred one that started this dicussion), so you are still going to contend the same resource for each (just "bucket hash mtx" instead of "giant", for the bucket type). Also, you probably want it to be a STAILQ. I'm not sure that this is actually a win?!? I guess if there are a bunch of these buckets, you would end up with different hash values for the mutexes... though relying on a hash seems wrong, since you can't really control collision domains that way; eventally, you will get people with widely different perofromance based on where the linker linked their bucket list head to, and that's probably not good. OTOH, A per CPU bucket list means no bucket mtx would be necessary; without that, it's just replacing one type of contention for another, I think, until you start making mutex selection indeterminate. 8^(. Really, this delayed freeing idea is starting to get uglier than just going to per CPU pools... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
