Subject: Re: Fun with Limits
To: Ben Harris <email@example.com>
From: Anders Magnusson <firstname.lastname@example.org>
Date: 02/08/2001 21:10:15
> In article <email@example.com> you write:
> >(2) data size limit presents a bit of a problem, because if it's _too_
> >large mmap-non-fixed mappings will have a hard time being satisfied
> >(in fact, IIRC, the mmap code won't _ever_ place non-fixed mappings in
> >that range).
> This is true, and is a serious pain on systems with small address spaces.
> To ensure that all processes can call mmap() (which malloc() does) on arm26,
> I have to arrange that MAXTSIZ + MAXDSIZ + MAXSSIZ < 24MB, even though any
> given process is unlikely to be hitting the text and data limits at the same
> time. This all needs to be made rather more dynamic.
The problem is similar on vax; even if the address space is 1G per
process the page tables eat giant amount of memory, and because the
mmap() area are located after MAXDSIZ the minimum amount of used page
table space is always == MAXDSIZ.
A nice way to solve this would be to remove sbrk(), learn malloc() to
understand non-contiguous memory and then intermix mmap()ed data and
malloced data. This would pack the address range to a minimum.