On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: > So, what you want is something like a > MGETHCL(m, how, type) > MHCLFREE(m) > interface which first looks in a combined freelist before the individual > mbuf and cluster freelists. I think it's a good idea.
I would prefer to see an interface that just grabs both a cluster and an mbuf from their respective per-CPU caches (in -CURRENT) while only grabbing the lock once, if at all this is that important to you. [*] In -CURRENT right now, clusters and mbufs are allocated from different per-CPU cache lists but they _share_ per-CPU locks, therefore this is entirely do-able. Having yet another cache that holds linked cluster + mbufs would really complicate allocations. [*] Admittedly, Alfred was pushing for exactly this not long ago, but I just didn't feel like doing it because I felt that there are better things to worry about than a little unlock + relock, when we're just dropping and re-acquiring the exact same lock, I don't see it as too big of a deal. However, I'm really not sure as to how smart architectures like Intel are with bus-locked instructions and data cache use. If they're stupid about it (i.e., if they don't look at caches during a bus-locked cycle), then it could be worth it to avoid that extra unlock/relock between allocations. If they're fairly smart about it, it's really not worth it. Also, I should mention that in his original message, Luigi mentions that MGETHDR and MCLGET are rather long macros, but in -CURRENT they are functions so there is not really much added code cache pollution. Regards, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
