svn commit: r246204 - head/sys/arm/include

[Andre Oppermann]

On 01.02.2013 18:52, Alan Cox wrote:
> On 02/01/2013 04:26, Andre Oppermann wrote:
>> Author: andre
>> Date: Fri Feb  1 10:26:31 2013
>> New Revision: 246204
>> URL: http://svnweb.freebsd.org/changeset/base/246204
>>
>> Log:
>>    Add VM_KMEM_SIZE_SCALE parameter set to 2 (50%) for all ARM platforms.
>>
>>    VM_KMEM_SIZE_SCALE specifies which fraction of the available physical
>>    memory, after deduction of the kernel itself and other early statically
>>    allocated memory, can be used for the kmem_map.  The kmem_map provides
>>    for all UMA/malloc allocations in KVM space.
>>
>
> Not always.  Off the top of my head, two things immediately come to
> mind: 9KB and 16KB jumbo frames come from the kernel map, because we
> allocate physically contiguous memory for them, and some swap metadata
> also comes from the kernel map.

I'd love to remove jumbo clusters that are larger than PAGE_SIZE.  The
hard need of s/g challenged network cards is gone.  All contemporary
networks can deliver a jumbo frame into a PAGE_SIZE'd mbuf cluster chains.
Some can even split off the headers into a separate mbuf.

A quick search for kernel_map allocations didn't show many other direct
users of the kernel_map.  The XEN net and blk backends do make use of it.

Other users have their own submaps: exec_map, pipe_map, buffer_map and
pager_map.

> Yes, all "ordinary" heap allocations come from the kmem map, but a
> number of things that are special for one reason or another don't.

-- 
Andre