On Fri, 20 Aug 1999, Thierry Vignaud wrote:
> "Stephen C. Tweedie" wrote:
> > The CPU doesn't support 64 bit pointers. Kind of makes it a bit
> > inefficient to access the user memory if you have to make a system call
> > every time. :)
> Yes, but we do can use 24:32 referencse (as
> pse36_extended_selectors:offset). Each process may own a ldt that allow
> him to own several 4Gb segment : code, data, stack, kernel mem mapped,
> librairies, shared mem (X11/dga -> fb mem and IPC shm).
HOLY SH*! (sorry). You don't mean that for real, do you? This would
completely break C and Unix and whatever else paradigm. If dealing with
pointers you'd have to know to which segment the pointer belongs: Is this
a pointer to a user or lib function, is this a pointer to a variable on
stack, userspace or in the lib. You could make the compiler use some
larger pointers, but as the 24:32 is probably again not a unique mapping
(because 24+32 > 36; I mean several selector:offset combinations refer to
the same memory location) it will be a pain for pointer arithmetic.
Yes, I know, generations of real mode compilers worked this way, and it
was a pain in the ass for anyone.
> As this could broke a lot of soft, we may define a flag in ELF header
> that select 2:2 split of ram or the new scheme.
A lot of soft? It will break ANY C-program except special applications.
> Another solution : add a new brk36 on ix86 that enable very big apps
> (such as oracle) to own multiple 4Gb segment and then give to the
> userland developper all the difficulties.
At least this does not break all programs and moves the burden of dealing
with the kludge to those apps that really want it. Better yet, simply
allow to run several (max 4G) apps using all real mem you have and write a
parallel/distributed program if you need more than 4G of memory.
> Yes, i know, if someone want a lot of mem, he should switch to a 64 bits
> arch, but there are now some servers which manage up to 16Go RAM. WinNT
> has put a choose a stupid trick and reinvent their classic solution
> (EMS, XMS, ...) by allowing apps to copy blocks from above the 4Gb mem.
> This is really stupid but they can say they manage more than 4Gb and not
> us.
The major point is, due to the majority of memory problems with any kind
on Win, even NT, I really doubt a 16GB NT server can do anything better
than a 1GB linux machine. Heck, I see daily that an NT with 128GB slows to
a crawl doing simple things like editing an ASCII file and running a
serial terminal emulator which run like a charm on my old 486 with 32.
THEY need this cludge to deal with even the simplest applications, WE
don't.
NT needs this memory NOW, because they already fail in standard
situations. Other than that, it's only a temporary kludge, they can't push
it ad infinitum. It might work for 16GB, maybe for 32 or 64 (oh, you said
its 36 bit only, so we are already at the limit of the kludge when we
start to implement it). But then? Due to the memory waste of MS, intel is
at the limit now. Either they move to a real 64 architecture (or something
x between 16 & 64; 8 byte per pointer definitely bloat programs) now with
the hacks it needs to support virtual 8068 and now maybe virtual protected
mode, or they don't and die.
So, we either wait for a 64bit intel, as we don't need this hack now, or
move to Alpha or Power when intel fails. Oh.. we are already on Alpha and
Power(maybe not the recent ones). So what. The linux hobbyist can run on
a cheap 4GB or less intel, if you need a professional system, just use
another architecture. As all uses plain C(++) paradigm and Unix, it's not
too difficult to write applications running on all these machines.
Michael.
--Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me.
- 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/