Messages in this thread | | | Date | Sat, 8 Jan 2000 00:29:16 +0100 (CET) | From | Peter Tufvesson <> | Subject | Re: Can a process use up more than 910MB? |
| |
On Fri, 7 Jan 2000, Lincoln Dale wrote:
> At 02:42 07/01/00 +0100, Peter Tufvesson wrote: > >Yes, so Linux can handle this if you have the source code. Now, this is > >not always the case. So if I have a pre-compiled program (commercial > >product, that is) that happens to use malloc() and not mmap(), I in fact > >have a system which only allows me 910MB per process. > > not that i disagree with you ... but i'm sure that there is probably good > reason for the memory map being set up the way it currently is.
I would love to hear it! No irony intended, I really would. Because I think both of us agree something should be done about this otherwise.
> dare i suggest it, but how about talking to this commercial-vendor and > explaining to them that they need to use a different malloc.
This is fundamentally interesting. Should the vendor make changes to suit Linux, or should it be the other way around? I for one say that Linux must be as good or better than other OSs if it wants to compete for commercial use. Remember that Linux claims to support 3GB of process virtual memory. I would say this is twisting with numbers...
> alternately, glibc's malloc could be made more intelligent.
Yes, this is true. Or why not have both a better allocation strategy and have a more intelligent libc? But a malloc() that uses mmap() and internally fragments the memory would be perfect, I guess!
> it is typically the case that programs that are designed to use large > amounts of RAM are already using mmap(), so the problem doesn't typically > exist . . .
Once again, I think the vendor/programmer should be free to choose for himself whether he wants to use mmap() or malloc(). The kernel should not force him/her in any direction.
/Peter
- 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/
| |