Re: changing MAXDSIZ/using more physical memory?
From: Chris Kantarjiev (cak+news_at_dimebank.com)
Date: 06/21/05
- Next message: Shane Almeida: "Staying current with -current"
- Previous message: tedu: "Re: Routerboard 532"
- In reply to: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Next in thread: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Reply: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 20 Jun 2005 17:56:04 -0700
tedu wrote:
>
> Chris Kantarjiev wrote:
>
>
>>I am investigating using an mmap'd file for the buffer, but would also like to
>>understand if I can increase the hard limit of RLIMIT_DATA. Is this being set by
>>the MAXDSIZ kernel parameter? Can I "just" raise that number in vmparam.h and
>>recompile, or are there some fundamental limits based on structure sizes?
>
>
> For all released versions, you can use mmap (with MAP_ANON, so you
> don't need a file either) to get around the limit. You won't be able
> to allocate it all at once, but with 2 or 3 calls you can come close.
> Changing anything in vmparam.h is a very bad idea.
>
Using mmap() would be a great idea if I was working in C. I'm not; I'm working
in python, so the code that allocates the arena is several layers down. Changing
it to use mmap() is not something I'm going to do in my spare time over the next
week.
So. Care to expound on *why* changing MAXDSIZ is a 'very bad idea'? I'd be happy
just to double it (to 2GB) which would still make certain that the kernel has
all the room it can want.
- Next message: Shane Almeida: "Staying current with -current"
- Previous message: tedu: "Re: Routerboard 532"
- In reply to: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Next in thread: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Reply: tedu: "Re: changing MAXDSIZ/using more physical memory?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|