From owner-svn-src-all@FreeBSD.ORG Mon Aug 26 14:18:36 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7F8C683 for ; Mon, 26 Aug 2013 14:18:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B06F274A for ; Mon, 26 Aug 2013 14:18:36 +0000 (UTC) Received: (qmail 6737 invoked from network); 26 Aug 2013 15:00:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Aug 2013 15:00:46 -0000 Message-ID: <521B63B7.70805@freebsd.org> Date: Mon, 26 Aug 2013 16:18:31 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: svn commit: r254779 - head/sys/kern References: <201308241224.r7OCOx9l069850@svn.freebsd.org> <20130826105033.GQ4574@FreeBSD.org> In-Reply-To: <20130826105033.GQ4574@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:18:36 -0000 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