Large memory bugfix for mprime 24.14.2

[S00113]

On an Opteron box with 16 GiB of RAM, it refuses to use anything other than 8 MiB. I get this message when trying to use the menu:

Daytime available memory in MB (7): 16128
Please enter a value between 8 and 8.
Daytime available memory in MB (7): 7
Please enter a value between 8 and 8.

It will not do P-1 stage 2 when I enter a larger value by hand in local.ini either.

Contents of /proc/meminfo:

MemTotal:     16254220 kB
MemFree:      15555472 kB
[...]
SwapTotal:    18876364 kB
SwapFree:     18876364 kB
[...]

The function physical_memory() expects an older format of /proc/meminfo where the first integer equals total memory in bytes, and return this value converted to MiB. This is OK for all kernels up to and including 2.4, but the first integer in recent kernels contain total memory in KiB. Now physical_memory() reads the amount of memory in KiB and returns the amount in GiB. According to mprime the computer is equipped with only 16 MiB of memory. Barely able to run a double check.

Fortunately this doesn't break completely on 2.6 kernels with less than 8 GiB of memory, because of another bug. mprime subtracts 8 from the unsigned long value returned from physical_memory(). This the reason why it suggested 7 above. When the amount of memory seen by mprime is less than 8 MiB, the result wraps around and becomes a very large number. Don't fix the last bug. It may be handy if Linux 3.14 or so decides to give the amount of memory in MiB.

This version should work on all kernels 2.0 and above. The function is defined in linux/prime.c line 489:

unsigned long physical_memory (void)
{
        FILE    *fd;
        char    mem[80];

        fd = fopen ("/proc/meminfo", "r");
        if (fd == NULL) return (1024);
        for ( ; ; ) {
                if (fscanf (fd, "%s", mem) == EOF) break;
                if (strcmp (mem, "MemTotal:") == 0) {
                        fscanf (fd, "%s", mem);
                        fclose (fd);
                        return (atoi (mem) >> 10);
                }
        }
        fclose (fd);
        return (1024);
}

[Prime95]

Does this code work instead? It was recommended by a user a month ago.


struct sysinfo sys_info;

if (sysinfo(&sys_info) != 0) {
return(1024);
}
return (sys_info.totalram >> 20);

[ColdFury]

Programs shouldn't really rely on information from /proc files, since their format may change without warning.

Yes, using sysinfo is better, though its Linux specific.

[Prime95]

Is the totalram field in sysinfo 32 bits? If so, won't 16GB of memory still cause problems?

[ColdFury]

Originally Posted by Prime95

Is the totalram field in sysinfo 32 bits? If so, won't 16GB of memory still cause problems?

http://www.die.net/doc/linux/man/man2/sysinfo.2.html

The "mem_unit" field tells you how many bytes each unit of "totalram" designates. So if "mem_unit" is 1024, and "totalram" is 1024, then the true amount of ram is a MB.

[S00113]

Originally Posted by Prime95

Does this code work instead?

It works, and so does return ((sys_info.totalram * sys_info.mem_unit) >> 20);

There is some weirdness. When I compile the program on RHEL 4 with a 2.6 kernel, my test program return 0 on a RHEL 3 machine running a 2.4 kernel. If I compile it on the RHEL 3 machine, the program works on both.

I don't have a Linux machine availiable with more than 16 GiB of RAM . On the 16 GiB machine sys_info.totalram is 16644321280 and sys_info.mem_unit is 1.

[ColdFury]

When I compile the program on RHEL 4 with a 2.6 kernel, my test program return 0 on a RHEL 3 machine running a 2.4 kernel.

Easy answer, don't compile programs (especially system-dependant ones like this) on one kernel version and expect them to run properly on another. The glibc code and binary interfaces for 2.4 and 2.6 are different.

[Prime95]

The code in v25 will be:

struct sysinfo sys_info;

if (sysinfo(&sys_info) != 0) return (1024); /* Guess 1GB */

return ((unsigned long)
((double) sys_info.totalram *
(double) sys_info.mem_unit / 1048576.0));