Cleanup and untangling of kernel VM initialization

[Andre Oppermann]

On 08.03.2013 10:16, Konstantin Belousov wrote:
> On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote:
>>    pager_map: is used for pager IO to a storage media (disk). Not
>>    pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256).
 >
> It is more versatile. The space is used for pbufs, and pbufs currently
> also serve for physio, for the clustering, for aio needs.

Good to know.  Isn't the ceiling of MAXPHYS * 256 a bit tight then?

>>    memguard_map: is a special debugging submap substituting parts of
>>    kmem_map. Normally not used.
>>
>> There is some competition between these maps for physical memory. One
>> has to be careful to find a total balance among them wrt. static and
>> dynamic physical memory use.
 >
> They mostly compete for KVA, not for the physical memory.

Indeed.  On 32bit architectures KVA usually is 1GB which is rather
limited.

>> Within the submaps, especially the kmem_map, we have a number of
>> dynamic UMA suballocators where we have to put a ceiling on their
>> total memory usage to prevent them to consume all physical *and/or*
>> kmem_map virtual memory. This is done with UMA zone limits.
 >
> Note that architectures with the direct maps do not use kmem_map for
> the small allocations. The uma_small_alloc() utilizes the direct map
> for VA of the new page. kmem_map is needed when allocation is multi-page
> sized, to provide the continuous virtual mapping.

Can you please explain the direct map some more?  I haven't found any
good documentation or comments on it.

>> It could be that some of the kernel_map submaps are no longer
>> necessary and their purpose could simply be emulated by using an
>> appropriately limited UMA zone. For example the exec_map is very small
>> and only used for the exec arguments. Putting this into pageable
>> memory isn't very useful anymore.
 >
> I disagree. Having the strings copied on execve() pageable is good,
> the default size of around 260KB max for the strings is quite a
> load on the allocator.

Oops.  You're right.  I didn't notice how big ARG_MAX can be.

-- 
Andre