FreeBSD 5.3 Bridge performance take II

[Brad Knowles]

At 1:55 AM -0700 2004-09-09, Matthew Dillon wrote:

>      If you don't believe that the slab allocator has severe performance
>      issues then the slab allocator (aka malloc()) should simply be used
>      directly.  If you do believe that the slab allocator has severe
>      performance issues then the correct solution is to FIRST FIX THE
>      SLAB ALLOCATOR.

	I think Robert's point was that we don't know for sure how badly 
this part of the system may be broken, or what the best fix is to 
apply.  My understanding is that he's trying to instrument the thing 
so that he can simulate various different alternatives and see which 
appears to be the best solution (if anything actually needs to be 
done).  Once that decision has been made, then you can start work on 
implementing the real solution.  You also get a nice prototype/second 
system effect as a result.

	The alternative which you seem to be advocating seems to me to be 
a classic case of "READY, FIRE, AIM!"

>      It seems clear to me that it makes little sense to spend time
>      on a per-thread memory cache when a per-cpu memory cache is, just from
>      an algorithmic point of view, going to be far more effective, far
>      easier to manage, possible to have larger (deterministic) hysteresis
>      without creating too much non-deterministic slop, and so on and so forth.

	You may believe that to be true, but I think Robert is saying 
that he wants to try to gather some hard evidence before he tries to 
implement any given solution.

>      If this is just an experiment, and therefore something that will never
>      be committed, then I still don't understand why you are even wasting time
>      working on it when you could be fixing the slab allocator instead.

	This seems to me to be a case of making some assumptions about 
where the cart may be and instead focusing exclusively on trying to 
first optimize the horse location.


	I don't know what Robert's ultimately going to do, but I 
appreciate the fact that he's taking time to try to measure various 
different options for the subsystem he's considering, before he 
starts slashing and burning in the codebase.

	More importantly, he's communicating with a relatively large 
group of important members of the user base as to what he's got 
cooking in his testbed, and telling us something of the methods he 
intends to use to measure the performance of the different options. 
This speaks volumes to me, and seems to be a wonderful change from 
the behaviour that we in this community have occasionally seen 
apparently coming from other people.

	Those other people may very well have been doing their own 
scientific measurement process before they started making changes. 
However, regardless of whatever they were doing behind closed doors, 
and whatever select members of core@ that they may have been talking 
to about these issues, I certainly don't recall seeing them talking 
to the current@ community about what they had going on before we had 
and announcement of a large-scale change sprung on us.


	Good communications with the user base is key.  Robert seems to 
me to be making a big improvement in this area, and I hope this is a 
trend that will continue.

>      Well, I guess identifying the problem areas is good, but it isn't
>      rocket science.  It should be glaringly obvious without requiring
>      all that much actual testing.

	I'm not convinced of that, at least not in this case.  Certainly, 
there are situations where a casual inspection of the code will 
identify glaring issues that need to be resolved.

	However, this is one of the most critical parts of the entire OS, 
and I think Robert is being very intelligent by deciding that he's 
going to try to avoid making any assumptions going in and will 
instead try all the various different options and see what works best.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.