[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_gnumach]] [[!toc]] # IRC, freenode, #hurd, 2011-02-15 etenil: originally, mach had its own virtual space (the kernel space) etenil: in order to use linux 2.0 drivers, it now directly maps physical memory, as linux does etenil: but there is nothing similar to kmap() or vmalloc() in mach, so the kernel is limited to its 1 GiB (3 GiB userspace / 1 GiB kernelspace) that's the short version, there is a vmalloc() in mach, but this trick made it behave almost like a kmalloc() braunr: the direct mapping is *only* for the benefit of Linux drivers?... also, the configuration of segments limits the kernel space antrik: i'm not sure, as i said, this is the short version antrik: but there is a paper which describes the integration of those drivers in mach you mean the linux 2.0 drivers? braunr: I read it once, but I don't remember anything about the physical mapping in there... etenil: well, originally it was 1.3, but essentially that's the same... i don't see any other reason why there would be a direct mapping 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 however, the kernel won't work in 64 bit mode without some changes to physical memory management and mmu management (but maybe that's what you meant by physical memory) ## IRC, freenode, #hurd, 2011-02-16 antrik: youpi added it for xen, yes antrik: but you're right, since mach uses a direct mapped kernel space, the true problem is the lack of linux-like highmem support which isn't required if the kernel space is really virtual # IRC, freenode, #hurd, 2011-06-09 btw, how can gnumach use 1 GiB of RAM ? did you lower the user/kernel boundary address ? I did 2G ? yes ok it doesn't make so much sense to let processes have 3G addressing space when there can't be more that 1G physical memory that's sad for an operating system which does most things by mapping memory eh well, if a process wants to map crazy things, 3G may be tight already e.g. ext2fs yes so there's little point in supporting them we need hurd/amd64 and there's quite some benefit in shrinking them to 2G yes actually even 2G may become a bit tight webkit linking needs about 1.5-2GiB things become really crazy wow 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 well, the Hurd doesn't "artificially" limits itself to 1.5GiB memory i386 has only 4GiB addressing space we currently chose 2GiB for the kernel and 2GiB for the userspace since kernel needs some mappings, that leaves only 1.5GiB usable physical memory Hm? 2GiB for kernel, 2GiB for userspace, 500MiB are used for what? for mappings such as device iomap contiguous buffer allocation and such things Ah, ok. You map things in kernel space into user space then. linux does the same without the "bigmem" support no, just in kernel space kernel space is what determines how much physical memory you can address unless using the linux-said-awful "bigmem" support # IRC, freenode, #hurd, 2012-07-05 hm i got an address space exhaustion while building eglibc :/ we really need the 3/1 split back with a 64-bits kernel 3/1? 3 GiB userspace, 1 GiB kernel ah the debian gnumach package is patched to use a 2/2 split and 2 GiB is really small for some needs on the bright side, the machine didn't crash there is issue with watch ./slabinfo which turned in a infinite loop, but it didn't affect the stability of the system actually with a 64-bits kernel, we could use a 4/x split # IRC, freenode, #hurd, 2012-08-10 all modern systems embed the kernel in every address space which allows reduced overhead when making a system call sometimes there is no context switch at all 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 using sysenter/sysexit makes it even faster [[open_issues/system_call_mechanism]]. # IRC, freenode, #hurd, 2012-12-12 youpi: is the 2g split patch really needed ? or rather, is it really a good thing for most people ? instead of the common 3g/1g it reduces tasks' address space but allows the kernel to reference more physical memory the thing is, because of the current page cache implementation, most of the time, this physical memory remains unused, or very rarely ? on the other hand, a larger address space for tasks allows running more threads (more space for tasks) and not failing while linking webkit .. :) it's needed for quite a few compilations, yes if you refer to the link stage, with a decent amount of swap, it goes without trouble well, if your kernel doesn't have 2GiB physical addressing capacity, userspace won't have >2GiB memory capacity either does it now? it didn't use to and it was crawling like hell for some builds (until simply hanging) i never have a problem e.g. runing the big malloc glibc test (bug22 or something like that) that doesn't involve objects from the fs, does it? no as long as it's anonymous memory, it's ok the default pager looks safe, i'm pretty sure our lockups are because of something in ext2fs braunr: well, an alternative would be to build two kernels, one 2/2 and one 3/1 not really worth it i was just wondering i usually prefer a 3/1 on darnassus, but i don't build as often as a buildd :x or we can go with 2.5/1.5 I can do that on bach & mozart for instance (they have their own kernel anyway) youpi: if you think it's worth the effort again, i was just wondering out loud braunr: well, bach & mozart don't have > 1.2GiB mem anyway so it doesn't pose problem # IRC, freenode, #hurd, 2013-01-12 can hurd have more than 1GB of ram ? sobhan: not with the stock kernel, but yes with a simple patch sobhan: although you should be aware of the implications of this patch (more kernel memory, thus more physical memory - up to 1.8 GiB - but then, less user memory) # IRC, freenode, #hurd, 2013-06-06 braunr: quick question, what memory allocation algorithms does the Mach use? I know it uses slab allocation, so I can guess buddy allocators too? no slab allocator for kernel memory (allocation of buffers used by the kernel itself) a simple freelist for physical pages and a custom allocator based on a red-black tree, a linked list and a hint for virtual memory (which is practically the same in all BSD variants) and linux does something very close too