On Fri, Jun 15, 2001 at 06:55:29PM -0500, Jonathan Lemon wrote:
> > In any case, the mb_alloc code you used still has the malloc() and
> > free() calls during cluster allocation and freeing and still, it looks to
> > me as very comparable nonetheless.
> The results look good to me; the only thing that really stands out
> is the signature graph for stream tests; that odd curve at the start
> of the run. However, if I'm interpreting it correctly, it shows
> better performance in the mb_alloc case.
Oh yeah, they're certainly decent, especially given that we're under
Giant. Remember that the scalability should come into play only when Giant
is unzipped, and then there is space for improvement. For me, all that matters
is that there is no significant degradation at this point, because the new
allocator has another significant advantage over the old one: possibility
of resource reclamation.
As for the `bulge' it is likely related to the fact that your old
allocator code may not be configured to pre-allocate enough mbufs and/or
clusters so it's stuck fetching from the map. But, in any case, although
mb_alloc does show to be slightly better here, keep in mind that the x-axis
is logarithmically scaled, so the difference is rather minimal.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message