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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:11 EST