Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2012 18:37:57 +0300
From:      Sergey Kandaurov <pluknet@gmail.com>
To:        Mark Saad <nonesuch@longcount.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Approaching the limit on PV entries
Message-ID:  <CAE-mSOK-JswcJXRPMfMxVZpc0H5gZ5-iv5H4-zDDPxfau=E=vA@mail.gmail.com>
In-Reply-To: <CAMXt9NapczKEmBU3Wwwh99jb6Vv9bhejxgpmVqStGBwvP7BmAA@mail.gmail.com>
References:  <CAMXt9NapczKEmBU3Wwwh99jb6Vv9bhejxgpmVqStGBwvP7BmAA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 22 November 2011 19:29, Mark Saad <nonesuch@longcount.org> wrote:
> Hello All

[found this mail in my drafts, not sure if my answer is still useful]

> =A0I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and
> 7.3-RELEASE I have seen the following warning in dmesg.
>
> Approaching the limit on PV entries, consider increasing either the
> vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
>
> So looking around I see a few posts here and there about how to tune
> the sysctls to address the warning however I am not 100% sure what
> each value does.
> It appears changing vm.pmap.shpgperproc affects the value of
> vm.pmap.pv_entry_max . Can someone explain the relationship of the two
> sysctls. Also

This is how they are calculated.

pv_entry_max =3D shpgperproc * maxproc + cnt.v_page_count;

and, respectively,

shpgperproc =3D (pv_entry_max - cnt.v_page_count) / maxproc;

So, changing one sysctl will change another and vice versa.

> what pitfalls of changing them are.

Not known to me (on amd64 platform).
I have had vm.pmap.shpgperproc=3D15000 on 8.1 amd64 with 4G RAM
to make some badly written commercial software to work until it
was decommissioned to the scrap.

> Also why would setting
> kern.ipc.shm_use_phys=3D1 =A0effect the pv entries. Is this supposed to
> lower the pv entries ?

Changing this sysctl with restarting a quite busy PgSQL server helped
me to reduce pv entries from 14M to tens of thousands (though that
could just coincide with decrease in workload).

--=20
wbr,
pluknet



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOK-JswcJXRPMfMxVZpc0H5gZ5-iv5H4-zDDPxfau=E=vA>