Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 May 2012 11:37:08 -0500
From:      Alan Cox <alan.l.cox@gmail.com>
To:        Charles Owens <cowens@greatbaysoftware.com>
Cc:        Adam Vande More <amvandemore@gmail.com>, freebsd-stable@freebsd.org
Subject:   Re: superpages not solving "PV entries" limit warning
Message-ID:  <CAJUyCcM09NsxEUz36mXvRf1w7gT5t4KG9afQwUxFZGpkndep0Q@mail.gmail.com>
In-Reply-To: <4FABE440.5000100@greatbaysoftware.com>
References:  <4FAAAF8E.40007@greatbaysoftware.com> <CA%2BtpaK2nOieH%2BLFwqDXRX-DRVXvhL3%2BcXfWPoskY6-xW5Qj-_g@mail.gmail.com> <CAJUyCcO7MoT0ux9aRxNtkMo2eij=NZ%2BiQ0jsh9j2hoH6wabPhw@mail.gmail.com> <4FABE440.5000100@greatbaysoftware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 10, 2012 at 10:52 AM, Charles Owens <cowens@greatbaysoftware.com
> wrote:

>  That's very helpful!  I had read about that and wondered if it applied to
> i386.
>
> Should I have expected "superpages" to completely cure the condition... or
> does it just help?  Should I now be looking at tuning the related pmap
> sysctls to give further relief?
>
>
Superpages won't cure the problem due to the nature of your workload.
After a fork, writes to portions of the address space that are both
superpages and copy-on-write will trigger demotion, or re-instantiation of
the 4KB page granularity PV entries.  Ultimately, repromotion to superpages
may occur, but in the meantime, your peak usage of PV entries is only
slightly reduced.

The bottom line is that you'll need to resort to tuning.

Alan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJUyCcM09NsxEUz36mXvRf1w7gT5t4KG9afQwUxFZGpkndep0Q>