1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
[[!meta copyright="Copyright © 2011, 2012 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
<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
[[open_issues/system_call_mechanism]].
|
