IRC, freenode, #hurd, 2011-02-15

<braunr> etenil: originally, mach had its own virtual space (the kernel
  space)
<braunr> etenil: in order to use linux 2.0 drivers, it now directly maps
  physical memory, as linux does
<braunr> etenil: but there is nothing similar to kmap() or vmalloc() in
  mach, so the kernel is limited to its 1 GiB
<braunr> (3 GiB userspace / 1 GiB kernelspace)
<braunr> that's the short version, there is a vmalloc() in mach, but this
  trick made it behave almost like a kmalloc()
<antrik> braunr: the direct mapping is *only* for the benefit of Linux
  drivers?...
<braunr> also, the configuration of segments limits the kernel space
<braunr> antrik: i'm not sure, as i said, this is the short version
<braunr> antrik: but there is a paper which describes the integration of
  those drivers in mach
<etenil> you mean the linux 2.0 drivers?
<antrik> braunr: I read it once, but I don't remember anything about the
  physical mapping in there...
<antrik> etenil: well, originally it was 1.3, but essentially that's the
  same...
<braunr> i don't see any other reason why there would be a direct mapping
<braunr> except for performance (because you can use larger - even very
  lage - pages without resetting the mmu often thanks to global pages, but
  that didn't exist at the time)

IRC, freenode, #hurd, 2011-02-15

<antrik> however, the kernel won't work in 64 bit mode without some changes
  to physical memory management
<braunr> and mmu management
<braunr> (but maybe that's what you meant by physical memory)

IRC, freenode, #hurd, 2011-02-16

<braunr> antrik: youpi added it for xen, yes
<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

IRC, freenode, #hurd, 2011-11-12

<youpi> well, the Hurd doesn't "artificially" limits itself to 1.5GiB
  memory
<youpi> i386 has only 4GiB addressing space
<youpi> we currently chose 2GiB for the kernel and 2GiB for the userspace
<youpi> since kernel needs some mappings, that leaves only 1.5GiB usable
  physical memory
<sea4ever`> Hm? 2GiB for kernel, 2GiB for userspace, 500MiB are used for
  what?
<youpi> for mappings
<youpi> such as device iomap
<youpi> contiguous buffer allocation
<youpi> and such things
<sea4ever`> Ah, ok. You map things in kernel space into user space then.
<youpi> linux does the same without the "bigmem" support
<youpi> no, just in kernel space
<youpi> kernel space is what determines how much physical memory you can
  address
<youpi> unless using the linux-said-awful "bigmem" support

IRC, freenode, #hurd, 2012-07-05

<braunr> hm i got an address space exhaustion while building eglibc :/
<braunr> we really need the 3/1 split back with a 64-bits kernel
<pinotree> 3/1?
<braunr> 3 GiB userspace, 1 GiB kernel
<pinotree> ah
<braunr> the debian gnumach package is patched to use a 2/2 split
<braunr> and 2 GiB is really small for some needs
<braunr> on the bright side, the machine didn't crash
<braunr> there is issue with watch ./slabinfo which turned in a infinite
  loop, but it didn't affect the stability of the system
<braunr> actually with a 64-bits kernel, we could use a 4/x split

IRC, freenode, #hurd, 2012-08-10

<braunr> all modern systems embed the kernel in every address space
<braunr> which allows reduced overhead when making a system call
<braunr> sometimes there is no context switch at all
<braunr> on i386, there are security checks to upgrade the privilege level
  (switch to ring 0), and when used, kernel page tables are global, so
  they're not flushed
<braunr> using sysenter/sysexit makes it even faster

system call mechanism.

IRC, freenode, #hurd, 2012-12-12

<braunr> youpi: is the 2g split patch really needed ?
<braunr> or rather, is it really a good thing for most people ?
<braunr> instead of the common 3g/1g
<braunr> it reduces tasks' address space but allows the kernel to reference
  more physical memory
<braunr> the thing is, because of the current page cache implementation,
  most of the time, this physical memory remains unused, or very rarely
<youpi> ?
<braunr> on the other hand, a larger address space for tasks allows running
  more threads (more space for tasks) and not failing while linking webkit
  .. :)
<youpi> it's needed for quite a few compilations, yes
<braunr> if you refer to the link stage, with a decent amount of swap, it
  goes without trouble
<youpi> well, if your kernel doesn't have 2GiB physical addressing
  capacity, userspace won't have >2GiB memory capacity either
<youpi> does it now?
<youpi> it didn't use to
<youpi> and it was crawling like hell for some builds
<youpi> (until simply hanging)
<braunr> i never have a problem e.g. runing the big malloc glibc test
<braunr> (bug22 or something like that)
<youpi> that doesn't involve objects from the fs, does it?
<braunr> no
<braunr> as long as it's anonymous memory, it's ok
<braunr> the default pager looks safe, i'm pretty sure our lockups are
  because of something in ext2fs
<youpi> braunr: well, an alternative would be to build two kernels, one 2/2
  and one 3/1
<braunr> not really worth it
<braunr> i was just wondering
<braunr> i usually prefer a 3/1 on darnassus, but i don't build as often as
  a buildd :x
<youpi> or we can go with 2.5/1.5
<youpi> I can do that on bach & mozart for instance
<youpi> (they have their own kernel anyway)
<braunr> youpi: if you think it's worth the effort
<braunr> again, i was just wondering out loud
<youpi> braunr: well, bach & mozart don't have > 1.2GiB mem anyway
<youpi> so it doesn't pose problem

IRC, freenode, #hurd, 2013-01-12

<sobhan> can hurd have more than 1GB of ram ?
<braunr> sobhan: not with the stock kernel, but yes with a simple patch
<braunr> sobhan: although you should be aware of the implications of this
  patch
<braunr> (more kernel memory, thus more physical memory - up to 1.8 GiB -
  but then, less user memory)

IRC, freenode, #hurd, 2013-06-06

<nlightnfotis> braunr: quick question, what memory allocation algorithms
  does the Mach use? I know it uses slab allocation, so I can guess buddy
  allocators too?
<braunr> no
<braunr> slab allocator for kernel memory (allocation of buffers used by
  the kernel itself)
<braunr> a simple freelist for physical pages
<braunr> and a custom allocator based on a red-black tree, a linked list
  and a hint for virtual memory
<braunr> (which is practically the same in all BSD variants)
<braunr> and linux does something very close too