I have a new version of the patch for you to test. It's up:
(same place as before).
The difference is that I have removed the HUGE src/sys sweep for #include's
and have removed the need to include <sys/malloc.h> before <sys/mbuf.h>.
This had the added effect of effectively nuking the allocation/deallocation
macros in sys/mbuf.h, which is good because what was previously there was
a pessimization. The reason it was a pessimization was because callers that
used the macros would only pay the cost of one function call but callers
that used the function equivalents would pay the cost of two function calls,
even in the best case scenario.
With these changes, all callers do one function call per allocation.
Bruce: Would you please glance over these changes (particularily the mbuf.h
and the bottom of subr_mbuf.c - m_get() and downward)? I think it
fixes the problem you brought up to me earlier today. :-)
Matt Jacob: If you have already started testing the other diff, that's okay,
nothing much has changed functionally. However, if you haven't
or if you have extra time, please consider backing it out and
applying this one. Sorry for the inconvenience.
On Wed, Jun 13, 2001 at 01:07:44AM -0400, Bosko Milekic wrote:
> Hi -current && -alpha,
> If you run -CURRENT on multiprocessor alpha, please
> please please read this! :-)
> The final version (or next to final, depending on how
> this final testing stage goes) of the new mbuf allocator which
> I have been working on for the past 1.5 months and which I've
> already mentionned on -arch is now ready.
> I plan to commit the new bits within the next week.
> However, as is usually the case with commits of this magnitude,
> I'd like a few more tests to be run by a few more people.
> I've been testing the allocator myself (in several different
> ways, mainly resource exhaustion simulations) for the past
> couple of weeks and have been able to catch and fix a couple
> of bugs.
> Also, jake, jlemon, and Silby (Mike Silbersack) have
> provided me with some reviews, all of which have been integrated
> into the latest version of the patch (below).
> The latest version of the "mb_alloc" code, applying
> to -CURRENT as of 5 minutes ago can be found here:
> People who have the following hardware are needed to help
> test the patch:
> 1- UP -CURRENT systems (Intel && Alpha)
> 2- SMP -CURRENT systems (Intel)
> 3- SMP -CURRENT systems (Alpha) *** Especially important ***
> who are *not* using the if_vx.c driver [*]
> [*] The if_vx.c driver is broken for the Alpha, and is marked so
> by this patch. Before committing this, I plan to first fix
> the driver but, obviously, for now, if you are
> using if_vx, you won't be able to help with testing. :-(
> To test the patch: apply, build, reboot, do network-related
> things, check stats with `netstat -m', etc.
> For those looking at the code:
> Finally, a few things should be noted about the code
> itself (if you're just helping test, feel free to skip this
> - I disabled mbtypes related statistics _FOR NOW_. This is
> because if I were to presently enable them, I wouldn't be
> able to consistently update them (unless I do it atomic()ally,
> which is not so good for overall performance). I plan to
> re-enable them later on, but would prefer to wait and
> go over them (perhaps clean them up - add/remove types as
> needed - many are if 0'd anyway) rather than rush and waste
> time doing it now.
> - The patch is big. sys/mbuf.h includes need to also #include
> <sys/malloc.h> _BEFORE_ because sys/mbuf.h requires
> MALLOC_DECLARE() to be defined.
> - counters for m_ext objects are now all malloc()ed. This will
> likely eventually change for what concerns clusters (I am
> looking at storing the cluster counter in the cluster 2
> region itself). For other object types, I plan to leave
> malloc() as the standard allocator for the counters, seeing
> as how the external objects are not allocated in a PCPU
> fashion anyway.
> That's it! This patch also sets up the way to more
> mbuf-related cleanups (i.e. obvious ones like merging uipc_mbuf.c
> code with uipc_mbuf2.c code, and ridding ourselves of the latter,
> etc.). It also moves a bundle of mbuf related things out of
> sys/conf/param.c and into subr_mbuf.c, where they will now
> belong. :-)
> Best Regards and PLEASE help test (especially if you have alpha
> Bosko Milekic
> [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message