Re: 64-bit question
Re: 64-bit question
- Subject: Re: 64-bit question
- From: AgentM <email@hidden>
- Date: Fri, 4 Nov 2005 09:52:52 -0600
On Nov 3, 2005, at 1:30 PM, Bob Bader wrote:
---------------- Observations from my users -----------------------
1. The "top" command does not display the correct memory
allocation status for a given process. To be precise, it is not
able to show the values for memory greater than 4GB so it's a kind
of hard to test high-mem applications. Looks like it's just the old
32bit "top", without 64bit capability.
Yes. Unfortunately, even the 64-bit app can't query how much memory
it is using because the kernel structures involved don't support 64-
bit-sized reporting. Oops!
http://lists.apple.com/archives/darwin-kernel/2005/Sep/msg00055.html
and the follow-up:
http://lists.apple.com/archives/darwin-kernel/2005/Sep/msg00061.html
2. We wrote and executed a custom C program to test the 64bit C
compiler the system came with. It also tests 64bit environment and
a system's general ability to handle high-mem apps. The application
was able to allocate about 15GB on your test box and ... then the
machine rebooted! Unacceptable!
The program is listed belowl, to compile it just execute:
gcc -arch ppc64 c-bigmem-test.c -o c-bigmem-test.exe
"c-bigmem-test.exe" is the output - an executable file you may run.
The program is straightforward and it just tries to allocate more
and more memory and it doesn't stop by itself (leave it or kill
it!). On the screen you'll see the value of current memory taken.
We tested it on the 64bit Linux /the memory status obtained from
64bit "top" matched the values printed out by our C program/ and
when all system resources (physical memory + swap/hdd/ memory ) ran
out, it was killed by the kernel which is correct.
That depends on your definition of "correct".
Linux (by default) employs the so-called Out-Of-Memory Killer (OOM
Killer) which allows malloc to overcommit and effectively lie about
how much memory is available for allocation. If the overcommitted
pages are then written (as you do below) then a heuristic takes over
in the kernel to kill (with SIGKILL) some program-- cross your
fingers and hope it doesn't kill your database or long-running number-
cruncher. More details and the way to shut this off at:
http://lwn.net/Articles/104179/
Obviously, you revealed a bug in the Darwin kernel's 64-bit handling
(and an easy-to-use DOS), but POSIX has a well-defined method of
notifying the program that there is no more memory- namely returning
NULL from malloc(). So please don't rely on the KILL behavior.
Here is the code
--------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define ARRAY_SIZE 1000000
int main(){
char **bigbuf;
char buf [ARRAY_SIZE];
long long int i=0;
for(i=0;i<ARRAY_SIZE;i++){
buf[i]='A';
}
bigbuf=malloc(ARRAY_SIZE*sizeof(char *));
if(bigbuf==NULL){
printf("Main malloc failed!\n");
}
i=0;
while(++i){
char * str_tmp=malloc(ARRAY_SIZE*sizeof(char));
if(str_tmp==NULL){
printf("Internal malloc failed!\n");
}
bigbuf[i]=str_tmp;
strcpy(bigbuf[i], buf);
if(i==0) {printf("MB allocated: %lld\n",i);};
}
return 0;
}
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40themactionfaction.com
This email sent to email@hidden
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
AgentM
email@hidden
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden