On 23.01.2013 00:22, Artem Belevich wrote:
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:
Should it be set to a larger initial value based on min(physical,KVM) space
available?
It needs to be
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:
Should it be set to a larger initial value based on min(physical,KVM)
space
available?
It needs to be smaller than the physical space, [...]
On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:
Should it be set to a larger initial value based on min(physical,KVM) space
available?
It needs to be smaller than the physical space, [...]
Or larger, as the address space can get fragmented and you might not be
able to
The autotuning work is reaching into many places of the kernel and
while trying to tie up all lose ends I've got stuck in the kmem_map
and how it works or what its limitations are.
During startup the VM is initialized and an initial kernel virtual
memory map is setup in kmem_init() covering the
I'll follow up with detailed answers to your questions over the weekend.
For now, I will, however, point out that you've misinterpreted the
tunables. In fact, they say that your kmem map can hold up to 16GB and the
current used space is about 58MB. Like other things, the kmem map is
auto-sized
On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann an...@freebsd.org wrote:
The (inital?) size of the kmem_map is determined by some voodoo magic,
a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables.
However it seems to work out to an effective kmem_map_size of about 58MB
on
6 matches
Mail list logo