Re: Cleanup and untangling of kernel VM initialization

On 03/08/2013 06:58, Andre Oppermann wrote:
> 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.
>


Take a look at a MIPS architecture manual.  Some architectures, such as
MIPS, provide an alternate mechanism for virtual-to-physical address
translation for use by the OS.  Typically, a range of virtual addresses
are reserved for this mechanism, and accesses to virtual addresses
within this range bypass the usual translation process involving TLBs
and page tables.  Often, but not always, this range covers the entire
physical memory of the machine, and both the forward mapping from
virtual to physical and the inverse mapping from physical to virtual are
trivially computed.

Sometimes we implement a direct map in software when none exists in
hardware, for example, amd64.  On amd64 we use large pages, either 2MB
or 1GB, to simulate a hardware-supported direct map.  Even though it is
not directly supported by hardware, it is nonetheless a useful
optimization because it can be used in preference to creating and
destroying mappings on as needed basis.


>>> 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.
>