From owner-svn-src-all@FreeBSD.ORG Sat Jul 7 08:35:42 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB451065673; Sat, 7 Jul 2012 08:35:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0188FC1C; Sat, 7 Jul 2012 08:35:40 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q678ZmO5025849; Sat, 7 Jul 2012 11:35:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q678Zam4036512; Sat, 7 Jul 2012 11:35:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q678ZabZ036511; Sat, 7 Jul 2012 11:35:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Jul 2012 11:35:36 +0300 From: Konstantin Belousov To: Marcel Moolenaar Message-ID: <20120707083535.GR2338@deviant.kiev.zoral.com.ua> References: <201207061557.q66Fv45N069464@svn.freebsd.org> <20120706181213.GI2338@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TDVcAd+kFgbLxwBe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org Subject: Re: svn commit: r238172 - head/sys/dev/agp X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 08:35:43 -0000 --TDVcAd+kFgbLxwBe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 06, 2012 at 06:11:56PM -0700, Marcel Moolenaar wrote: >=20 > On Jul 6, 2012, at 11:12 AM, Konstantin Belousov wrote: >=20 > >> agp_i810.c: > >> While arguably the use of Maxmem can be considered correct, replace i= ts use > >> with realmem anyway. agp_i810.c is specific to amd64, i386 & pc98, wh= ich > >> have a dense physical memory layout. Avoiding Maxmem here is done wit= h an > >> eye on copy-n-paste behaviour in general and to avoid confusion cause= d by > >> using realmem in agp.c and Maxmem in agp_i810.c. > > The agp_i810.c use is to prevent attachment when largest physical addre= ss > > of populated memory exceeds GPU limits established by PTE format and > > chipset errata. Editing Maxmem to be spelled as realmem seems to change > > nothing right now, but I do argue that this is wrong, and commit message > > makes future archeology quite confusing. >=20 > The commit log states it all, including how one can arguably call the cha= nge > wrong. What exactly is confusing? The realmem is supposed to report available memory on the system, and not the highest physical memory address. Current calculation of maxmem as realmem is already wrong, often by 1GB on typical desktop machine, and I believe that it will become worse in the future. The platform does has all capacity to report non-dense layouts to OS, and OS is capable of supporting them already. I remember there were already reports of some IBM machines which have sparce address space, making maxmem/(real realmem) be a factor of 2. Confusing is the use of the amount of memory for decision that needs highest address. Commit log just restates the change made without any motivation, I think it is backward. --TDVcAd+kFgbLxwBe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/39NcACgkQC3+MBN1Mb4iHUACgnKT68Xj/HSWKIzAAsChHWMSf I40AnjoEXF2B5ZYOKzudgDhtRzjdBdLl =pHxF -----END PGP SIGNATURE----- --TDVcAd+kFgbLxwBe--