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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
