From owner-svn-src-head@FreeBSD.ORG Thu Nov 19 16:15:21 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4D258106566B; Thu, 19 Nov 2009 16:15:20 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Robert Watson Date: Thu, 19 Nov 2009 11:15:01 -0500 User-Agent: KMail/1.6.2 References: <200911182340.nAINeJ3W087652@svn.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911191115.11088.jkim@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r199498 - in head/sys: amd64/amd64 i386/i386 net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:15:21 -0000 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. :-) > Also, in 9.x I'm going to be looking at parallel execution within > BPF descriptors, and I notice that the JIT compiles the register > array pointer into the generated code, rather than allowing a > pointer to be passed in to each instance. I guess it's non-trivial > to change that, suggesting that we have a pool of compiled > instances, but it would be preferable to be able to do what the > normal BPF code does: allocate a per-thread register block when > needed. It is non-trivial but certainly not impossible. Jung-uk Kim