Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Mar 2012 11:12:10 +0300
From:      Sergey Kandaurov <pluknet@freebsd.org>
To:        Alan Cox <alc@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r233290 - head/sys/amd64/amd64
Message-ID:  <CAE-mSO%2BFe8_xDU9%2BPnQBxWR2EF=P8wB2REyhnHgeuz9ojndQwQ@mail.gmail.com>
In-Reply-To: <201203220440.q2M4eMSl007771@svn.freebsd.org>
References:  <201203220440.q2M4eMSl007771@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 22 March 2012 08:40, Alan Cox <alc@freebsd.org> wrote:
> Author: alc
> Date: Thu Mar 22 04:40:22 2012
> New Revision: 233290
> URL: http://svn.freebsd.org/changeset/base/233290
>
> Log:
> =A0Change pv_entry_count to a long. =A0During the lifetime of FreeBSD 10.=
x,
> =A0physical memory sizes at the high-end will likely reach a point that
> =A0the number of pv entries could overflow an int.
>
> =A0Submitted by: kib
>
> Modified:
> =A0head/sys/amd64/amd64/pmap.c
>

While there, maybe also do something with these semi-debug-ish
vm.pmap.pc_chunk_(allocs|frees) like change them to [u_]long too, move
under debug or just drop them? While they can be useful for someone,
pc_chunk_(allocs|frees) have also an "int" and quite quickly overflow.
Though e.g. vm.pmap.pv_entry_(allocs|frees) have a long.

--=20
wbr,
pluknet



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSO%2BFe8_xDU9%2BPnQBxWR2EF=P8wB2REyhnHgeuz9ojndQwQ>