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

[Alan Cox]

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