mike@cimcor.mn.org (Michael Grenier) (01/12/89)
From article <1289@uwbull.uwbln.UUCP>, by ckl@uwbln.UUCP (Christoph Kuenkel): John talks about a standard UNIX System V.2 kernel which Microport appears to use for their V/AT product (to their credit). I had asked why the brk call always requires the entire process to swap/relocate in memory or swap to disk. > In article <10746@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >> Well, now you know ;-) Had a realloc been added these problems wouldn't >> exist. I had added a realloc() which tested for adjacency and it resolved >> this problem partially. The conclusion I reached was that processes >> should allocate physical memory in large chunks and then manage the >> unused space, rather than growing one click at a time. >> + My solution is to estimate the maximum size of dynamic memory a process will + need and code something like: + + ... + register char *p; + + p = malloc(ESTIMATED_SIZE); /* 1. */ + (void) malloc(1); /* 2. */ + free(p); + + Step 1 is to grow the process with a single swap out/swap in, step 2 is + to avoid shrinking of the process's break value. + + Seems to work quite fine. Is it much more stupid than I realize? + (Yes, I dont use the maximum size for long-running programs with extensively + varying memory usage) Chris, Your method would work fine on a non-brain damaged CPU. My problem however exists on an Intel 80286 processor where one can only malloc or increase the break value by one segment at a time or less than 64K bytes at a time. Thus if I know the process is going to consume 1 megabyte of RAM, the process has to allocate 1M/64K or at least 16 times. Each time I allocate a block, the process swaps more slowly which is very fustrating when its obvious that the memory is available. Moreover, the 80286 processor wouldn't even need that memory to be contigous to the given process since its virtual memory via selectors will map the process addresses to various segments throughout physical RAM. John's method of adding a realloc call within the kernel is probably a good idea on a 80286 if reasonably fast brk/sbrk/mallocs are going to be achieved for user processes. Hopefully, Microport can look into this problem. -Mike Grenier mike@cimcor.mn.org uunet!rosevax!cimcor!mike
dorman@sdsioa.UUCP (Leroy Dorman X42406) (01/13/89)
Back in '86 we incrporated 'realloc'-like functionality into the generic V.2-286 (for multibus 1 Intel 310's) and improved performance on out 1Mb RAM machines for ld jobs by up to 40%! (operations like rebuilding kernels, etc.) I guess uPort assumes all AT's have lots of core . . . Eric Dorman siolmd!eric@sdsioa