From owner-svn-src-all@FreeBSD.ORG Fri Nov 20 06:39:29 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C41106566C; Fri, 20 Nov 2009 06:39:29 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 181FF8FC12; Fri, 20 Nov 2009 06:39:28 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 5509B2C2D87; Fri, 20 Nov 2009 00:39:28 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AaL+zKdw-nY5; Fri, 20 Nov 2009 00:39:20 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id EBE662C2D89; Fri, 20 Nov 2009 00:39:19 -0600 (CST) Message-ID: <4B063997.2010900@cs.rice.edu> Date: Fri, 20 Nov 2009 00:39:19 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: John Baldwin References: <200911182340.nAINeJ3W087652@svn.freebsd.org> <200911191115.11088.jkim@FreeBSD.org> <200911191649.37198.jhb@freebsd.org> In-Reply-To: <200911191649.37198.jhb@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, Robert Watson , Jung-uk Kim Subject: Re: svn commit: r199498 - in head/sys: amd64/amd64 i386/i386 net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 20 Nov 2009 06:39:29 -0000 John Baldwin wrote: > On Thursday 19 November 2009 11:15:01 am Jung-uk Kim wrote: > >> On Thursday 19 November 2009 03:26 am, Robert Watson wrote: >> >>> On Wed, 18 Nov 2009, Jung-uk Kim wrote: >>> >>>> - Change internal function bpf_jit_compile() to return allocated >>>> size of the generated binary and remove page size limitation for >>>> userland. - Use contigmalloc(9)/contigfree(9) instead of >>>> malloc(9)/free(9) to make sure the generated binary aligns >>>> properly and make it physically contiguous. >>>> >>> Is physical contiguity actually required here -- I would have >>> thought virtual contiguity and alignment would be sufficient, in >>> which case the normal trick is to allocate using malloc the size + >>> min-align + 1 and then fudge the pointer forward until it's >>> properly aligned. >>> >> I don't believe it is strictly necessary but I assumed it might have >> performance benefit for very big BPF programs although I have not >> measured it. Also, contigmalloc(9)/contigfree(9) is too obvious to >> ignore for this purpose. :-) >> > > Why would it have a performance benefit to have the pages be physically > contiguous? contigmalloc() is expensive and should really only be used if > you truly need contiguous memory. If you can get by with malloc(), just use > malloc(). > > If anything, there is a performance benefit from using malloc. Kernel memory allocated with malloc on amd64 is likely to be backed by superpages. This is not true of contigmalloc. Alan