Date: Mon, 26 Aug 2013 16:18:31 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r254779 - head/sys/kern Message-ID: <521B63B7.70805@freebsd.org> In-Reply-To: <20130826105033.GQ4574@FreeBSD.org> References: <201308241224.r7OCOx9l069850@svn.freebsd.org> <20130826105033.GQ4574@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521B63B7.70805>