Messages in this thread | | | Date | Thu, 3 Aug 2000 15:07:51 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: Memory management... |
| |
On Thu, 3 Aug 2000, Richard B. Johnson wrote:
> On Wed, 2 Aug 2000, Tigran Aivazian wrote: > > > On Wed, 2 Aug 2000, Richard B. Johnson wrote: > > > So what did you expect? Now turn on user limits. > > > > did you actually try your own suggestion? Iwas rather puzzled by the fact > > that turning on the user limits is obviously not enough. Or at least not > > the obvious user limits (RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS) but a > > rather unobvious one - RLIMIT_AS. This is because malloc(3) uses not just > > brk(2) system call (which honours RLIMIT_DATA) but > > mmap(MAP_PRIVATE|MAP_ANONYMOUS) which honours RLIMIT_AS. > > No I did not. If the writer had said they he had found a way to bypass > user limits then I would have been more receptive. However, merely > submitting some code that will run the system out of memory and > stating that it will lock up the system, left no hint that he was > using user limits. Also, where did you find that he was using a > special malloc()? DEFAULT_MMAP_THRESHOLD on glibc-2.0.6 that I have the > source for is 128 * 1024. His code does not magically hit a boundary.
it does (probably due to a bug and not intentionally as his code looked awful anyway). It keeps failing for a long time and then eventually hits a very large old_mmap() request which succeeds and that lets him allocate 1G (on my machine) unless you set RLIMIT_AS appropriately. Try it - although now things are all clear so it is no longer interesting...
Regards, Tigran
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |