RE: [MiNT] memory fragmentation

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Thomas Binder
> Sent: Tuesday, August 17, 1999 8:30 PM
> To: MiNT mailing list
> Subject: Re: [MiNT] memory fragmentation
>
>
> Hi!
>
> On Sun, Aug 15, 1999 at 04:22:25PM +0200, Guido Flohr wrote:
> > As Jo already said, the proper solution would be to make the kernel
> > use the MMU what it had been designed for, for virtual memory
> > management.
>
> Well, without virtual address spaces this won't help much, but I fear a
> lot of GEM applications will cease to work, then, due to the many
> protocols using pointers to exchange data between applications. How
> would you want to do this? Automagically make all Mxalloced() memory
> shared? I think it's not easy to find a solution here, but maybe I'm
> just overlooking something.

Well -- any memory which is Mxalloc'ed as non-private needs to reside in a
global memory space. Where's the problem???

> > Apart from the need for VM I think that there are really some things
> > that could at least reduce fragmentation.  My first idea shouldn't be
> > that hard to implement: Under Magic the kernel evaluates a program
> > flag that tells the kernel that the program has reserved space for
> > the stack in the BSS.
>
> This flag will be evaluated in the next beta, I just sent my diffs to
> Frank. Additionally, you can now specify how much memory a normal
> process (i.e. without F_SMALLTPA set) should get in addition to its
> segments, via the new mint.cnf keyword "INITIALMEM".
>
> Thus, if you put
>
> INITIALMEM=2048
>
> into your mint.cnf, all processes will have (at most) a TPA which is
> text+data+bss+2048k.
>
> This is quite different to MAXMEM, especially because it does _not_
> limit further memory allocation of the processes.

Sounds good.