svn commit: r199498 - in head/sys: amd64/amd64 i386/i386 net
Jung-uk Kim
jkim at FreeBSD.org
Thu Nov 19 22:31:14 UTC 2009
On Thursday 19 November 2009 04:49 pm, 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().
Remember are allocating memory for a function pointer here. If we
want to take care of alignment, then "fudging the pointer forward"
trick is not going to be easy unless I embed real offset in the
structure and pass it around with the pointer. I don't mind doing it
but it seemed unnecessary to me. Besides, it is very unlikely to see
a lot of parallel BPF filter allocations in real world. Actually,
that is a big assumption for BPF JIT compiler by itself because
filter compilation is expensive. Also, if contigmalloc() fails,
bpf(4) simply falls back to good old bpf_filter(). So, I don't see
anything wrong with this.
Jung-uk Kim
More information about the svn-src-all
mailing list