svn commit: r238172 - head/sys/dev/agp

[Konstantin Belousov]

On Fri, Jul 06, 2012 at 06:11:56PM -0700, Marcel Moolenaar wrote:
> 
> On Jul 6, 2012, at 11:12 AM, Konstantin Belousov wrote:
> 
> >>  agp_i810.c:
> >>  While arguably the use of Maxmem can be considered correct, replace its use
> >>  with realmem anyway. agp_i810.c is specific to amd64, i386 & pc98, which
> >>  have a dense physical memory layout. Avoiding Maxmem here is done with an
> >>  eye on copy-n-paste behaviour in general and to avoid confusion caused by
> >>  using realmem in agp.c and Maxmem in agp_i810.c.
> > The agp_i810.c use is to prevent attachment when largest physical address
> > 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.
> 
> The commit log states it all, including how one can arguably call the change
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20120707/4b33869c/attachment.pgp