On Fri, May 31, 2002 at 02:02:27AM -0700, Terry Lambert wrote: [...] > Bottom line? > > I'd like to see one set of uniform semantics. > > It really disturbs me that the behaviour of a common flag changes > for some code, because of a sysctl, but doesn't change for all code > using the flag. > > I'd also like to see one set of code, if it can be negotiated between > you and the SLAB allocator guy. N allocators is usually N-1 too many, > IMO.
Yes, it was my intention to co-ordinate with JeffR and perhaps in a year from now (once UMA really stabilizes and I get the current backlog in my TODO well, out of the backlog) to take a stab at having the mbuf code use uma for allocations. This is why I delayed any further design work in mb_alloc for the moment. I agree that having fewer allocators is a Good Thing and have considered this with the Good of the Project in mind (as opposed to personal issues, ego, or whatever). :-) In any case, when the time comes to really tackle the issue, we will have to be very very careful. mb_alloc was written in such a way that mbuf allocations are optimized out and that for all common-case allocations, ONE function call is performed for the allocation, not more. I remember initially getting a very hard time from you and the lists on keeping the performance numbers up for mbuf allocations (we are known for having very fast mbuf allocation) and I also recall many nights of performance measurement and data gathering. My observation was that: 1) Getting rid of the large macros and moving to mb_alloc, even with Giant in place, slightly improved overall speed (I still have the data, actually: http://www.freebsd.org/~bmilekic/code/mb_alloc/results.html ) This is particularly the case for i386, where the negative cache effects of those large allocation/free macros was really noticable. 2) Increasing the common-case for allocations and frees to more than one single function call resulted in a noticable [albeit slight] slowdown, in the alpha in particular (unfortunately, something happened with jlemon's alpha stats so the graphs are no longer accessible). This is why I worked hard to place the allocation code in such a way to keep it at at most one function call for the common case. I'd like to maintain this assumption when/if we move to uma in the future. > -- Terry Cheers, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
