On 26.08.2013 12:50, Gleb Smirnoff wrote:
On Sat, Aug 24, 2013 at 12:24:59PM +0000, Andre Oppermann wrote:
A> Author: andre
A> Date: Sat Aug 24 12:24:58 2013
A> New Revision: 254779
A> URL: http://svnweb.freebsd.org/changeset/base/254779
A>
A> Log:
A> Avoid code duplication for mbuf initialization and use m_init() instead
A> in mb_ctor_mbuf() and mb_ctor_pack().
m_init() is inline, but it calls m_pkthdr_init() which isn't inline. It
might be that compiler inline it due to m_pkthdr_init() living in the same
file as mb_ctor_mbuf() and mb_ctor_pack(), but not sure.
It depends on the optimization level.
m_pkthdr_init() zeroes much more than deleted code did. Some zeroing
operations are definitely superfluous job.
It's exactly the same for mb_ctor_mbuf() and one more for mb_ctor_pack().
Overall it has become more because we've got a couple more (small) fields
in the mbuf headers now. Looking at the size of the headers it may be
faster to just bzero() it instead of doing it one by one.
The overall problem is that replicating the same operations in multiple
places is dangerous from a consistency point of view.
The change is definitely not an no-op change. It might have pessimized
the mbuf allocation performance.
Heavy inlining is not always an advantage and cause i-cache bloat. But
you're right I haven't benchmarked it (yet) and thus we don't know.
I've been setting up my 10G benchmark environment but had to re-prioritize
due to the impeding freeze on -current. If the benchmarking shows a conclusive
pessimization I'm more than happy to compensate for it, either by inlining
m_pkthdr_init() as well or some form of macro. Such changes can still be
done during API freeze, but before BETA1.
--
Andre
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
