FreeBSD 5.3 Bridge performance take II
brad at stop.mail-abuse.org
Thu Sep 9 08:07:29 PDT 2004
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.
More information about the freebsd-current