From 1c8909017d006c8e4afeea6d1a1efdebe26fc6b0 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Fri, 15 Jul 2011 22:46:18 +0200
Subject: IRC.

---
 microkernel/mach/gnumach/memory_management.mdwn | 30 +++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

(limited to 'microkernel/mach/gnumach/memory_management.mdwn')

diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 17c7ad79..43b99d83 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -50,3 +50,33 @@ IRC, freenode, #hurd, 2011-02-16
     <braunr> antrik: but you're right, since mach uses a direct mapped kernel
       space, the true problem is the lack of linux-like highmem support
     <braunr> which isn't required if the kernel space is really virtual
+
+
+---
+
+IRC, freenode, #hurd, 2011-06-09
+
+    <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the
+      user/kernel boundary address ?
+    <youpi> I did
+    <braunr> 2G ?
+    <youpi> yes
+    <braunr> ok
+    <youpi> it doesn't make so much sense to let processes have 3G addressing
+      space when there can't be more that 1G physical memory
+    <braunr> that's sad for an operating system which does most things by
+      mapping memory eh
+    <youpi> well, if a process wants to map crazy things, 3G may be tight
+      already
+    <youpi> e.g. ext2fs
+    <braunr> yes
+    <youpi> so there's little point in supporting them
+    <braunr> we need hurd/amd64
+    <youpi> and there's quite some benefit in shrinking them to 2G
+    <youpi> yes
+    <youpi> actually even 2G may become a bit tight
+    <youpi> webkit linking needs about 1.5-2GiB
+    <youpi> things become really crazy
+    <braunr> wow
+    <braunr> i remember the linux support for 4G/4G split when there was enough
+      RAM to fill the kernel space with struct page entries
-- 
cgit v1.2.3