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

[John Baldwin]

On Thursday 19 November 2009 5:31:00 pm Jung-uk Kim wrote:
> 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.

Why does a function pointer matter?  Fudging the pointer forward will always 
work as virtual addresses always have the same sub-page alignment as physical 
addresses, so doing something like:

	foo *realp;
	void *p;

	align = 16;
	p = malloc(size + (align -1));
	realp = (foo *)(roundup2((uintptr_t)p, align));

Will always work to give a 16-byte aligned pointer.  However, the in-kernel 
malloc() already gives you aligned memory anyway.  Are you seeing any panics
or buggy behavior when using malloc()?

-- 
John Baldwin