lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: using more than 2 GB as a ram disk
Date
>> The Alpha only has about 43 address bits; is the Alpha not 64-bit?
>
> The Alpha can be extended to 64 bits **WITHOUT SOFTWARE IMPACT**.

Note that you can still use the 4 kB pages to get better resolution.
I left them out of the original plan only because they seem to
make most people misinterpret the system.

Pages subdivide the larger chunks. There are 2048 real pages in an
8 MB segment, but those need not be the numbers. You could instead
use 8 kB "pages", each composed of 2 hardware pages. (Linus once
mentioned this -- I'm not crazy here at least) Assuming you only need
a 35-bit address space, you get 512 "pages" in a 4 MB segment.
If you prefer, have 64 kB pages and 16 MB segments. Whatever you like.

Terms I will use:

page = small unit, typically 4 kB to 64 kB size (a logical page)
Each page is a constant number of hardware pages.

chunk = large unit, typically 2 MB to 8 MB size
Each chunk is represented by a segment.

(in the simple version, those were the same huge size)

Pages are not completely independent of chunks. Chunks let us bypass
the 32-bit virtual address space, while pages make mmap() better,
reduce page fault time, and reduce memory waste.

Processes can take both page faults and chunk faults. Consider:

A. The chunk is mapped (a valid segment) but the page (hardware pages)
is (are) not present. This is a simple page fault.

B. The chunk is not mapped, but the page is present. That is, the system
still has a disconnected page table tree and some pages that would
be mapped if that tree were assigned to a segment register. This is
a chunk fault.

C. The chunk is not mapped and the page is not present. This is a
combination fault. (both page fault and chunk fault)

It should be obvious that the chunk size used by the OS does not
directly influence the page size as seen by userspace. There is
this relationship:
hardware page <= logical page <= chunk

Compatibility with BSD NFS servers would suggest an 8 kB logical page.

>>> you either store pointers in a non-flat format or normalize
>>> them every time;
>>
>> Yes, exactly. For userspace, this is hidden by the compiler.
>>
>>> once (or if) Intel adds more adds more address bits than 36
>>> you're hosed again.
>>
>> At that point I expect a fix for the virtual address space too.
>> If not, you can extend the hack a bit. Don't use Electric Fence.
>
> ... and your old binaries are worthless.

No, they work fine. Old binaries can not run with a large page size,
but that is not a serious problem.

> These kinds of proposals have been around for a long time (I remember
> seeing them back in the i386 days, using external logic.) They're
> just as useless now as then.

Usefulness requires a CPU that can handle segment issues quickly.
The Pentium Pro is hopeless, but the Pentium II might be OK enough.

Even if performance is horrid, this hack could have some value.
Marketing will love it :-) and I could reproduce 64-bit problems
on a normal PC. The hack looks fun too.


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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.067 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site