How FreeBSD manage more than 4GB on 32 bits architecture

[Pierre-Yves Péneau]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/09/2015 03:10 PM, Arthur Chance wrote:
> On 09/04/2015 11:00, Pierre-Yves Péneau wrote:
>> 
>> On 04/09/2015 11:49 AM, Ralf Mardorf wrote:
>>> On Thu, 9 Apr 2015 11:49:41 +0200, Eduardo Morras wrote:
>>>> You are looking for PAE.
>>> 
>>> Hi,
>>> 
>>> PAE does not support up to 8TB as the OP mentions. PAE is
>>> limited to 64 GiB.
>>> 
>>> 
>> 
>> Sorry, I forgot something important. My physical memory is 1TB,
>> and as Ralf said, PAE is limited to 64GB (36 bits). I'm looking
>> for a 40 bits support (at least).
> 
> I've just realised the original post said
> 
>> According to the architecture handbook(*), "FreeBSD could 
>> theoretically handle memory configurations up to 8TB on a 32 bit
>>  platform."
> 
> Having followed the link, I find that's a partial quote, and the
> full one was
> 
> "In fact, if the mmu were capable of it, FreeBSD could
> theoretically handle memory configurations up to 8TB on a 32 bit
> platform. However, since most 32 bit platforms are only capable of
> mapping 4GB of ram, this is a moot point."
> 
> I.e. it was talking about the software architecture of the kernel 
> virtual memory manager on 32 bit processors, not the hardware.
> 
> I think everybody has been assuming an Intel architecture, but a 32
>  bit Intel processor can't address 1TB as PAE is specifically
> defined as having a 36 bit (64GB) address bus. If your CPU is 32
> bits with 1TB of memory addressable, what on earth is it?

I did not want give too much details in my first email to avoid
confusion, but this is exactly what I bring.. So let's be more clear :-)

I'm working on an European project called TSAR(*). This project aims to
create a TeraScale ARchitecture with low consumption. That's why 32 bits
processors were chosen.
Our architecture is cc-NUMA. We have 256 clusters (maximum). Each
cluster contains 4 processors and have 4GB of RAM. MMUs can translate 32
bits virtual addresses into 40 bits physical addresses using two
coordinates, which are used to identify each cluster. These coordinates
are on 4 bits, each. So, a physical address is build like this:

| X coord(4 bits) | Y coord (4 bits) | Vaddr (32 bits) |

That's how we obtain 40 bits of addressable space, and why we have 1TB
of physical memory.

So, I've the required hardware I think. My problem is to find out how
FreeBSD can use this mechanisms. But I'm realizing that it may be not a
kernel issue, because it's an hardware functionality which should works
with Linux too. Right ?


(*) Maybe it's more clear than my explanations:
    https://www-asim.lip6.fr/trac/tsar/wiki

- -- 
+---------------------------------------------------------------+
| Pierre-Yves Péneau (#3361856)        |   SoC - LIP6 - UPMC    |
| Couloir 24-25 Bureau 417             |   first.last at lip6.fr   |
| 4 place Jussieu 75252 Paris Cedex 05 |   +33 1 44 27 54 15    |
+---------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVJpTzAAoJEPy7VC2L9m/AYecQALUYUNEx5UlF2b7LleDqbgn6
Nyr7O70u0DUMnjBZqIucbT2r57B0qQgQ5wcpUHD4Knu+dikbtgBk1/r7bD0hJA4X
Wa57C8jyrFAxFIlTNXRXbXAnsxD2pPQl1i8rwT2L3mbGEQWm95fUkUddfh4eovE4
tSshg1FAdHHwx7IwJtJCH71OeLzLIadgwb7cIygsTzIMN+eVY0BVYn7Jcbu5Uv2f
GV+btokwOjjCfwG9aCEFkAHkiGc3+Q8xV22Fb7r/VM3Qfv2XhG7qoLFNvnaJ+UYG
PwYoeWsxHIQ7ZcHyuZ9K0cyXLNnyHoSHLDdv1we1j7V/7I0722lUO3SxioRcw7ZY
PMYtnwK8lIkP94kOzFkU/IeCn1b1ywcO2gsGTnmaR0sPtW1JdwBzKT5wggl+Yo84
U/rvOsx1S1/jE35SRQyKGLe2RvzYpgaBxfxfgjZrqZrr6Lt6gY1FpWPNKeJ67P2g
lArtHMnEeTTcN47LAbxNzk8464cdH6/Kq6uMfbCILY+CPvco3HQ+o0wWujEBfLVH
zF9VZTEAu08BEGaq4D7w53V62oiRbGPrI5NOdSsJjaewSW2+CXF+txG0B2r+nkzd
N0JHYWNgQTpME8o9ec/z+q27GTruyKqPHa2uXyjzembchBUeZd6zr25o9ThqIKHb
wieu4TyWvOtNR2wMWG/r
=hz/g
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8BF66FC0.asc.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20150409/301415b4/attachment.sig>