Re: questions about VM_KMEM_SIZE_SCALE
Thank you both very much. This fills in the gaps nicely and I think I have a pretty good grip on this now. I feel like I can tune it a bit without worry now. (and avoid those nasty panics. :-) ) Thank you very very much. Jay On Thu, 26 Jun 2003, Terry Lambert wrote: > David Schultz wrote: > > On Tue, Jun 24, 2003, Jay Kuri wrote: > > > Does changing this affect memory available to user programs if it's unused > > > by the kernel? > > > > No, KVA_PAGES affects the memory available to user programs. (You > > have a 4 GB address space on i386 to split between user programs > > and the kernel.) Within the kernel's share of this address space, > > memory is split into submaps, such as the mb_map (for the > > network), buffer_map for the filesystem buffer cache, and the > > kmem_map for just about everything else. These submaps are > > size-limited to prevent any one of them from getting out of hand. > > > > The vm_kmem_map is sized automatically based on the amount of > > memory you have. Specifically, > > > > kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > > VM_KMEM_SIZE_MAX) > > > > The default value for VM_KMEM_SIZE_SCALE is 3, and the default > > VM_KMEM_SIZE_MAX is 200MB. > > David is exactly right in what he has said. Some minor ommisions > about the implications of what he has said, though, are: > > 1)The intent of doing this is to ensure that, for a given > amount of physical memory, you don't grab more than > 1/VM_KMEM_SIZE_SCALE * 100 % of it (default: 50%) for > the kmem_map. > > 2)If you *need* a much larger kmem_map, you are limited to > 200K, no matter how much physical memory you have, unless > you raise VM_KMEM_SIZE_MAX, as well. > > 3)If you want to explicitly control the memory size, you can > set VM_KMEM_SIZE_SCALE very, very large, which will cause > the second term in the "max()" expression to approach zero, > and then set VM_KMEM_SIZE_MAX = VM_KMEM_SIZE = > to disable the "min()" expression. > > 4)The kmem_map is used to allocate kernel structure having to > do with memory management; if you have a very large amount > of memory in your system, you should consider increasing > VM_KMEM_SIZE_MAX, at a minimum, but realize that you are > competing for KVA with all ather uses of kernel memory, so > if your KVA space is 2G, and you have 4G of RAM, and your > VM_KMEM_SIZE_SCALE is 2 and you set VM_KMEM_SIZE_MAX so it > doesn't clamp the top end, you can run yourself out of KVA > space. IMO, it would be good to use something like > min(Physical Memory, KVA space) in place of Physical Memory > as the first term of the min() expression. > > 5)It's generally useful to set VM_KMEM_SIZE_MAX huge, and > then use only VM_KMEM_SIZE_SCALE to adjust how much of > the physical RAM you allow the kmem_map to use (subject to > the limits in #4, above). > > 6)Physical memory allocated to backing KVA resident maps > like kmem_map don't reduce the amount of virtual memory > available to user space processes; however, actually using > the full KVA space worth of physical memory might mean that > user space processes compete for physical RAM where they > wouldn't before, and so it may mean swapping. Memory in > KVA maps is generally type-stable and can't be reclaimed > for user process use (i.e.: the kernel does not page, except > for speciall allocated memory sections, and they are not > generally used for anything important enough to get a map > entry). > > -- Terry > - - - - - - - - - - - - - - - - - - - - - - - - - - - Nothing fails like success because you do not learn anything from it. The only thing we ever learn from is failure. Success only confirms our superstitions. Jay Kuri [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questions about VM_KMEM_SIZE_SCALE
David Schultz wrote: > On Tue, Jun 24, 2003, Jay Kuri wrote: > > Does changing this affect memory available to user programs if it's unused > > by the kernel? > > No, KVA_PAGES affects the memory available to user programs. (You > have a 4 GB address space on i386 to split between user programs > and the kernel.) Within the kernel's share of this address space, > memory is split into submaps, such as the mb_map (for the > network), buffer_map for the filesystem buffer cache, and the > kmem_map for just about everything else. These submaps are > size-limited to prevent any one of them from getting out of hand. > > The vm_kmem_map is sized automatically based on the amount of > memory you have. Specifically, > > kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > VM_KMEM_SIZE_MAX) > > The default value for VM_KMEM_SIZE_SCALE is 3, and the default > VM_KMEM_SIZE_MAX is 200MB. David is exactly right in what he has said. Some minor ommisions about the implications of what he has said, though, are: 1) The intent of doing this is to ensure that, for a given amount of physical memory, you don't grab more than 1/VM_KMEM_SIZE_SCALE * 100 % of it (default: 50%) for the kmem_map. 2) If you *need* a much larger kmem_map, you are limited to 200K, no matter how much physical memory you have, unless you raise VM_KMEM_SIZE_MAX, as well. 3) If you want to explicitly control the memory size, you can set VM_KMEM_SIZE_SCALE very, very large, which will cause the second term in the "max()" expression to approach zero, and then set VM_KMEM_SIZE_MAX = VM_KMEM_SIZE = to disable the "min()" expression. 4) The kmem_map is used to allocate kernel structure having to do with memory management; if you have a very large amount of memory in your system, you should consider increasing VM_KMEM_SIZE_MAX, at a minimum, but realize that you are competing for KVA with all ather uses of kernel memory, so if your KVA space is 2G, and you have 4G of RAM, and your VM_KMEM_SIZE_SCALE is 2 and you set VM_KMEM_SIZE_MAX so it doesn't clamp the top end, you can run yourself out of KVA space. IMO, it would be good to use something like min(Physical Memory, KVA space) in place of Physical Memory as the first term of the min() expression. 5) It's generally useful to set VM_KMEM_SIZE_MAX huge, and then use only VM_KMEM_SIZE_SCALE to adjust how much of the physical RAM you allow the kmem_map to use (subject to the limits in #4, above). 6) Physical memory allocated to backing KVA resident maps like kmem_map don't reduce the amount of virtual memory available to user space processes; however, actually using the full KVA space worth of physical memory might mean that user space processes compete for physical RAM where they wouldn't before, and so it may mean swapping. Memory in KVA maps is generally type-stable and can't be reclaimed for user process use (i.e.: the kernel does not page, except for speciall allocated memory sections, and they are not generally used for anything important enough to get a map entry). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questions about VM_KMEM_SIZE_SCALE
On Tue, Jun 24, 2003, Jay Kuri wrote:
>
> Hi there,
>
> Can anyone shed some light on the implications of adjusting
> VM_KMEM_SIZE_SCALE? In particular I'm wondering if I increase this to,
> say, 2, what happens? I must admit I don't know how KVA is different from
> KVM or total RAM... so the note in kern_malloc ("on an x86 with 256M KVA,
> try to keep VM_KMEM_SIZE_MAX at 80M or below") doesn't shed enough light
> on the matter. What are the implications of VM_KMEM_SIZE getting large?
>
> Does changing this affect memory available to user programs if it's unused
> by the kernel?
No, KVA_PAGES affects the memory available to user programs. (You
have a 4 GB address space on i386 to split between user programs
and the kernel.) Within the kernel's share of this address space,
memory is split into submaps, such as the mb_map (for the
network), buffer_map for the filesystem buffer cache, and the
kmem_map for just about everything else. These submaps are
size-limited to prevent any one of them from getting out of hand.
The vm_kmem_map is sized automatically based on the amount of
memory you have. Specifically,
kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE),
VM_KMEM_SIZE_MAX)
The default value for VM_KMEM_SIZE_SCALE is 3, and the default
VM_KMEM_SIZE_MAX is 200MB.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
questions about VM_KMEM_SIZE_SCALE
Hi there,
Can anyone shed some light on the implications of adjusting
VM_KMEM_SIZE_SCALE? In particular I'm wondering if I increase this to,
say, 2, what happens? I must admit I don't know how KVA is different from
KVM or total RAM... so the note in kern_malloc ("on an x86 with 256M KVA,
try to keep VM_KMEM_SIZE_MAX at 80M or below") doesn't shed enough light
on the matter. What are the implications of VM_KMEM_SIZE getting large?
Does changing this affect memory available to user programs if it's unused
by the kernel?
Thanks for any assistance,
Jay
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Nothing fails like success because you do not learn
anything from it. The only thing we ever learn from
is failure. Success only confirms our superstitions.
Jay Kuri [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
