svn commit: r199498 - in head/sys: amd64/amd64 i386/i386 net

[Jung-uk Kim]

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