[[!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 mach isn't a true modern microkernel, it handles a lot of resources, such as high level virtual memory and cpu time for example, the page replacement mechanism can't be implemented outside the kernel yet, it provides nothing to userspace server to easily allocate resources on behalf of clients so, when a thread calls an RPC, the cpu time used to run that RPC is accounted on the server task the hurd uses lots of external memory managers [[external_pager_mechanism]]. but they can't decide how to interact with the page cache the kernel handles the page cache, and initiates the requests to the pagers braunr, why can't they decide that? because it's implemented in the kernel and there is nothing provided by mach to do that some other way 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 [[open_issues/mach_migrating_threads]]. slpz_: migrating threads only fix the issue for the resources managed by mach, not the external servers slpz_: but it's a (imo necessary) step to completely solve the issue in addition to being a great feature for performance (lighter context switchers, less state to track) it also helps priority inversion problems braunr: I was referring just to cpu-time, but I agree with you an interface change is needed for external pagers slpz_: servers in general, not necessarily pagers 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 [[open_issues/resource_management_problems]]. # [[open_issues/memory_object_model_vs_block-level_cache]]