Re: [OFFTOPIC] Re: [bigmem-patch] 4GB with Linux on IA32

Scott Lurndal (slurn@griffin.engr.sgi.com)
Fri, 20 Aug 1999 10:46:32 -0700 (PDT)


> Sorry, I was slightly taken away by the subject, I fear this went a
> little too offtopic.
>
> 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.

Not to mention that this scheme still won't allow access to more
than 4GB without a CR3 change and/or page directory pointer table change.

The 36-bit address extensions still require kernel intervention
to access more than 4GB at one time, as the segment registers only
accomodate a 32-bit flat address space.

PAE partitions the 4GB flat address space into 4 1GB sections, each
of which can be changed by altering the entry in the page directory pointer
table [see section 3.8.3 ia sw developers manual, vol. 3]. There is no
way to access more than at any one point in time, no matter what ldt
entries you have or what segment overrides are used.

> > 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.

Certain applications, like oracle, really run well if you give them
loads of RAM. (As pointed out above, you can't give it more than
4GB at one time, but you can use a windowing scheme with kernel
intervention to map a window into a larger than 4GB shared memory
segment, for example, to the application. Unixware does this
to utilize the additional memory provided by PAE on ia32 arch).

>
> > 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

Interestingly enough, NT currently holds the record for best TPC-C
results on the intel architecture; in large part because it provides
a mechanism (whether it is grody or not) to provide access to that
cache space for SQL server.

> 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.

This is arrogance at best, and foolishness at worst. Instead of
belittleing this competetive operating system (in this case,
somewhat unfairly), how about concentrating on how we can
overcome the often misleading perceptions that folks have
of open source operating systems, such as linux, in
a positive fashion? In fact, linux does have some shortcomings,
as does NT. No operating system (except perhaps SVR4/MK from
Unisys :-) is perfect.

>
>
> 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

Man O' Man!!!! You really can't mean this. You are relegating
linux to the hobbiest market with statements like this. It is clear
that to compete in the commercial marketplace, you have to provide
what the customer wants, not what you think the customer needs. If
the customer is Informix, for instance (just try to tell <name db company>
they need to rewrite their application because linux won't support PAE
because someone thinks it is ugly).

Tchuss,

Scott

-
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/