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...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message