On 23.01.2013 00:22, Artem Belevich wrote:
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek 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
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek 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, [...]
>
> O
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
On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann 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 my 16GB AMD64 d
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 ba
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 e
6 matches
Mail list logo
