On Sat, Jun 29, 2002 at 04:11:20PM -0700, Alfred Perlstein wrote: > If the pool is per-device-softc then it doesn't need locks and will > be a lot more efficient than even grabbing from the per cpu pool.
We have an allocator that does per-CPU allocations, we don't need to add additional layers of caches on top of that. The only thing you would save would be avoiding having to lock and unlock a cache. Since the lock is a per-CPU lock (because the caches are per-CPU), the contention on it is very low unless, of course, you get pre-empted somewhere during the allocation and then migrate CPUs; but this is not that likely to happen, really (not right now, anyway). > Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! Huh? If you're referring to the grouped mbuf + cluster allocation interface, I haven't yet admitted that it is worth it. I specifically said that it depends on how the architecture deals with bus-locked instructions and cache use. In other words, it depends on how expensive a unlock+relock operation is when we're dealing with the same lock. If we're allowed to go to the cache during the bus-locked unlock+relock ops, then we should be getting cache hits so strictly speaking, them being there is not such a big deal. But again, I have no idea what happens with cache interactions during a bus-locked instruction. > hah! :) > > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
