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
|
[[!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-08-05
< neal> braunr: For instance, memory objects are great as they allow you to
specify the mapping policy in user space.
< neal> braunr: But, the policy for determining the eviction order is
realized by Mach
< neal> braunr: And user-space has no control
< braunr> are you referring to the page cache lru approximation and stuff
like resource containers ?
< neal> I'm not sure what you mean by page cache lru appoximateion
< braunr> the kernel eviction policy :)
< neal> that's an implementation detail
# IRC, freenode, #hurd, 2011-09-05
<braunr> mach isn't a true modern microkernel, it handles a lot of
resources, such as high level virtual memory and cpu time
<braunr> for example, the page replacement mechanism can't be implemented
outside the kernel
<braunr> yet, it provides nothing to userspace server to easily allocate
resources on behalf of clients
<braunr> so, when a thread calls an RPC, the cpu time used to run that RPC
is accounted on the server task
<braunr> the hurd uses lots of external memory managers
[[external_pager_mechanism]].
<braunr> but they can't decide how to interact with the page cache
<braunr> the kernel handles the page cache, and initiates the requests to
the pagers
<cjuner> braunr, why can't they decide that?
<braunr> because it's implemented in the kernel
<braunr> and there is nothing provided by mach to do that some other way
<slpz_> braunr: you probably already know this, but the problem with client
requests being accounted on behalf the server, is fixed in Mach with
Migrating Threads
[[service_solahart_jakarta_selatan__082122541663/mach_migrating_threads]].
<braunr> slpz_: migrating threads only fix the issue for the resources
managed by mach, not the external servers
<braunr> slpz_: but it's a (imo necessary) step to completely solve the
issue
<braunr> in addition to being a great feature for performance (lighter
context switchers, less state to track)
<braunr> it also helps priority inversion problems
<slpz_> braunr: I was referring just to cpu-time, but I agree with you an
interface change is needed for external pagers
<braunr> slpz_: servers in general, not necessarily pagers
<slpz_> as a way to mitigate the effect of Mach paging out to external
pagers, the folks at OSF implemented an "advisory pageout", so servers
are "warned" that they should start paging out, and can decide which
pages are going to be flushed by themselves
[[service_solahart_jakarta_selatan__082122541663/resource_management_problems]].
# [[service_solahart_jakarta_selatan__082122541663/memory_object_model_vs_block-level_cache]]
|
