From owner-freebsd-questions@FreeBSD.ORG Fri Apr 10 09:17:20 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA605BF8 for ; Fri, 10 Apr 2015 09:17:20 +0000 (UTC) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by mx1.freebsd.org (Postfix) with ESMTP id 40A073F0 for ; Fri, 10 Apr 2015 09:17:19 +0000 (UTC) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.15.1/lip6) with ESMTP id t3A9HIOp001958 for ; Fri, 10 Apr 2015 11:17:18 +0200 (CEST) X-pt: isis.lip6.fr Received: from [0.0.0.0] (chomsky.torservers.net [77.247.181.162]) (authenticated bits=0) by asim.lip6.fr (8.15.1/8.14.4) with ESMTPSA id t3A9HFFM007637 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 10 Apr 2015 11:17:17 +0200 (MEST) Message-ID: <55279523.3070207@asim.lip6.fr> Date: Fri, 10 Apr 2015 11:17:23 +0200 From: =?windows-1252?Q?Pierre-Yves_P=E9neau?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: How FreeBSD manage more than 4GB on 32 bits architecture References: <5526408F.1090005@asim.lip6.fr> <20150409114941.692910293a8120de4dafd400@yahoo.es> <20150409114906.6dd4379c@archlinux> <55264DC5.9070606@asim.lip6.fr> <55267A63.4040503@qeng-ho.org> <55269509.1080103@asim.lip6.fr> <447ftkoqe6.fsf@lowell-desk.lan> In-Reply-To: <447ftkoqe6.fsf@lowell-desk.lan> Content-Type: multipart/mixed; boundary="------------060206050104000205060601" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (isis.lip6.fr [132.227.60.2]); Fri, 10 Apr 2015 11:17:18 +0200 (CEST) X-Scanned-By: MIMEDefang 2.75 on 132.227.60.2 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:17:21 -0000 This is a multi-part message in MIME format. --------------060206050104000205060601 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/10/2015 01:04 AM, Lowell Gilbert wrote: > Pierre-Yves Péneau writes: > >> 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 ? > > That is a bit of an oversimplification. The quote that led you to > make your original post indicates a problem with the Linux mapping > model which would not apply to using FreeBSD on your architecture. That's exactly what I thought, but that's your documentation which led me to this conclusion. The "Unlike Linux" part confused me. I thought that FreeBSD had a better physical memory management than Linux (maybe, but not for what I'm looking for). I think you should add something concerning the page table size, like you said in your previous email. That's the answer I was looking for, and it may be useful for those who have the same question (even if nobody in the world except me is trying to deal with 1TB and 32 RISC processors). > That's relatively minor, though. Your architecture has its own page > table design, which makes sense to me on its own, but I don't have > a sense of how much space the page table itself will take up. > Obviously a page table for 1TB of 4KB pages is already too big for > a 32-bit address space, even before you try mapping in the actual > pages. So the page sizes will clearly average out much larger. > > My guess would be that the key design issue for you will be how > your project's page table model fits into the interface of each > OS's VM system. I can't give much advice in that area, though -- I > tend to deal with embedded systems, which have entirely separate > sets of challenges. > > Best wishes. _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions To > unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > Thank you. - -- +---------------------------------------------------------------+ | Pierre-Yves Péneau (#3361856) | SoC - LIP6 - UPMC | | Couloir 24-25 Bureau 417 | first.last@lip6.fr | | 4 place Jussieu 75252 Paris Cedex 05 | +33 1 44 27 54 15 | +---------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVJ5UNAAoJEPy7VC2L9m/AsdMQAKgXFWNLPYVBfxpRMw/ycsfP qJkYpozND5daSd/1ha/XYX5G3asZDKidYc3m+IK3TD4YIatB6UAgXU8lXNR7OEa5 8hExg+/qv9mD0D2dEtwiB65WMuAPsBINGXAPtSgU/IGLv4FeG/jBtOha7Y4IDsPv epIZsUiSAOanxPKJROa0pVatBnxEWYt4auP/GRJ/j3jCKb1lHsakhr4NaZ91iy7E 9CruDQ1kr6iN82HCKugCBn2GWrQnV5AKcmBfTdFwi6ibnJWpt7Wof5ASM/VYHSBn v1ym/PfZapxThiPtXEfsKsDdSYk4XAP2AfFRewVXbW3EV82h40UK0PF7xt2zsKm4 L+Q+8ZxoINi3PwCHaU/rb53QXQoRLM5QYfg5nwYCZtC962A8O+D4BN67NzVFJwGk tHqyAstXaFFEgjuUQubDw57oT5x/RWNcISsnS+uH1kvdNrElQFcmX24V07Vg7nar Dxcvdw14FcsQu3pXdZoDHRlaD3M0MwaoE8e/fN42dTU9OfFqITp51gVDls48I0AV MOVgMgi1lT05AQbARwsaB70eB5qa8Y2zavNZ+GRx+TLnFAfBPCN1HLprqbZHzHuB yITzMxgjQeGdGJIRfiH1BR9eE38ZKiPBVcta69UPH3KeuuFHKdQiXRP3oXVoKS/B OJ52Ye1urDl27TnjuMoZ =+0iS -----END PGP SIGNATURE----- --------------060206050104000205060601 Content-Type: application/pgp-signature; name="0x8BF66FC0.asc.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0x8BF66FC0.asc.sig" iQIcBAABCAAGBQJVJ5UNAAoJEPy7VC2L9m/AlDAQAMQkonlMQkOPLz5eIFylNOncGM1GrVU6 5fWV6P7Qq2IfTt28NQB2vPJX7gBE/v22h/R2x9KeZKwEJFntowMkEi0JO5xVi4BTapROSC+j tPCbiS7AJgvyyxg7MczN2kPsp94y1y4yoE0AUVP07dZKzzNoIkkOWBzCMbLhe8kjaBdYKdfY MV/JRDYpKntELSdzcfJHBC85nLeNlmanqyApBOv+/HASkZCQfL33f8g1SJ8Ro1LB05cHQRSc MM+rq19xv2JvbbNVEXEFkEZ/dsOpC9Q2CDs8Ac95ntcV5iyt54Dyb3FbCSx+hO4x0jlxDe/Y cbGmOY7NhlgOh04830wpiilxAEAWPATh+/NzyBpKiXSVkMgrCHkxG4GNyIhcksa0cM1+/PGJ KzTiLA3U7hw4M7KpmMKL389bTs5AaJd6iLsa7YzJBZsrKcwhAcuZ5QbjCg71yH9dgthnLmi0 XIIvz7ZgnTgl9cjpJof4sLcYI8X869dcLMp7QBP6OgocTkOnzdp5n5nstfyM/nUw8lj9ma6F OTMemlFY7IiMU7M4E6vddcJE7w6S0YxQYLVByNgLARvmhLy6ihdVmyL/i+vSMB1IZt/mY+PQ 0NN+72YeWLobDyeCTaBqJA9aOWv0x2ti3lggUrt2BRyN8Q4EJToDxyHJ6STjYpidnpwBVXwH s9i6 --------------060206050104000205060601--