johnl@well.UUCP (John A. Limpert) (10/26/87)
I have noticed something odd with malloc on microport. When I run a programs that does alot of malloc calls that allocate relatively small chunks of memory, the program gets swapped to disk at a very high rate. This seems to start once a certain amount of memory has been allocated. It commonly occurs when I edit large files with MicroEMACS or when running pathalias. My machine has about 2.7 MB but the swapping starts long before the program has used any sizeable fraction of the total available RAM. Once the program starts being swapped it spends 90% of its time being swapped. I suspect that something is happening with the allocation of segments and the segment descriptor tables that causes the swapping. Is there any way to work around this problem? The system will thrash when I edit a 200k file and I know there is more than enough memory available.
rupley@arizona.edu (John Rupley) (10/26/87)
In article <4299@well.UUCP>, johnl@well.UUCP (John A. Limpert) writes: > I have noticed something odd with malloc on microport. When I run > a programs that does alot of malloc calls that allocate relatively > small chunks of memory, the program gets swapped to disk at a very > high rate. This seems to start once a certain amount of memory has > been allocated. It commonly occurs when I edit large files with > MicroEMACS or when running pathalias. My machine has about 2.7 MB I have found the same problem, under microport sysV/AT.2.2, and sent a bug report to microport. No response. I would be grateful for any help. Is the problem "unfixable", ie tied to the Intel segmented architecture? For anyone who wants to verify the malloc problem, the following code shows it. John Rupley uucp: ...!ihnp4!arizona!rupley voice: 602-325-4533 ****************cut here************************ # To unbundle, sh this file echo unbundling makefile 1>&2 cat >makefile <<'AlBeRtEiNsTeIn' CFLAGS= -Ml maltst: maltst.o cc $(CFLAGS) maltst.o -o malloc.test size malloc.test AlBeRtEiNsTeIn echo unbundling maltst.c 1>&2 cat >maltst.c <<'AlBeRtEiNsTeIn' /* malloc.test.c test of malloc for large files problem-- after about 300 kbytes of allocation, the system behaves oddly: ps shows no valid text pointer and a "growing" process things seem stranger when compiled with malloc library */ #include <stdio.h> #include <malloc.h> main(argc, argv) int argc; char **argv; { extern void exit(); extern char *malloc(); char *lp; unsigned limit; unsigned i; unsigned size; if (argc < 3) { printf("usage: %s malloc_size number_of_mallocs\n", argv[0]); exit(-1); } size = (unsigned )atoi(argv[1]); limit = (unsigned )atoi(argv[2]); printf("\n\n"); for (i = 0; i < limit; i++) { lp = malloc(size); printf("lp = %lx bytes = %ld\r", lp, (long )((i+1)*size)); } printf("\n\n"); exit(1); } AlBeRtEiNsTeIn
jmsully@uport.UUCP (John M. Sully) (11/06/87)
In article <2562@megaron.arizona.edu>, rupley@arizona.edu (John Rupley) writes: > In article <4299@well.UUCP>, johnl@well.UUCP (John A. Limpert) writes: > > I have noticed something odd with malloc on microport. When I run > > a programs that does alot of malloc calls that allocate relatively > > small chunks of memory, the program gets swapped to disk at a very > > high rate. This seems to start once a certain amount of memory has > > been allocated. It commonly occurs when I edit large files with > > MicroEMACS or when running pathalias. My machine has about 2.7 MB > > I have found the same problem, under microport sysV/AT.2.2, > and sent a bug report to microport. No response. I would be > grateful for any help. Is the problem "unfixable", ie tied > to the Intel segmented architecture? I talked with one of the engineers here about this problem and he suggested the following theory (this is a paraphrase, forgive any inaccuracies): Whenever an sbrk(2) call is made to grow the size of the process the system must check to see if sufficient swap space exists to swap out the new, larger process. What is suspected to be happening is that the swap space is being rearranged to make room for the larger process. I have noticed this behavior in programs which I have written here. A suggested work-around is to: 1) Allocate a full segment and then free it immediately, and then allocate space until this space is used. (This prevents doing an sbrk call for each malloc.) 2) Reinstall the system and allocate more swap space on the disk. Although I haven't tried this, the idea here is that with the larger swap space it won't take as long to find the space necessary to swap out the process. (I'll try this in a couple of days and let you all know what happens.) 3) Get a 386 box (this solves alot of other troubles too) :-). -- John M. Sully UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs Microport Systems ARPA: uport!techs@ucscc.UCSC.EDU Technical Support