summaryrefslogtreecommitdiff
path: root/hurd/translator/tmpfs
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2011-11-30 21:21:45 +0100
committerThomas Schwinge <tschwinge@gnu.org>2011-11-30 21:21:45 +0100
commitbe4193108513f02439a211a92fd80e0651f6721b (patch)
treea8fa187c9a6d4ba806a1b7799fa82f712f667c4e /hurd/translator/tmpfs
parentbe49aa7ddec52e121d562e14d4d93fd301b05fbb (diff)
IRC.
Diffstat (limited to 'hurd/translator/tmpfs')
-rw-r--r--hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn37
1 files changed, 37 insertions, 0 deletions
diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
index a9317c21..5228515f 100644
--- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -233,3 +233,40 @@ See also: [[open_issues/resource_management_problems/pagers]].
I have never looked at it.
[[open_issues/mach-defpager_vs_defpager]].
+
+
+# IRC, freenode, #hurd, 2011-11-08
+
+ <mcsim> who else uses defpager besides tmpfs and kernel?
+ <braunr> normally, nothing directly
+ <mcsim> than why tmpfs should use defpager?
+ <braunr> it's its backend
+ <braunr> backign store rather
+ <braunr> the backing store of most file systems are partitions
+ <braunr> tmpfs has none, it uses the swap space
+ <mcsim> if we allocate memory for tmpfs using vm_allocate, will it be able
+ to use swap partition?
+ <braunr> it should
+ <braunr> vm_allocate just maps anonymous memory
+ <braunr> anonymous memory uses swap space as its backing store too
+ <braunr> but be aware that this part of the vm system is known to have
+ deficiencies
+ <braunr> which is why all mach based implementations have rewritten their
+ default pager
+ <mcsim> what kind of deficiencies?
+ <braunr> bugs
+ <braunr> and design issues, making anonymous memory fragmentation horrible
+ <antrik> mcsim: vm_allocate doesn't return a memory object; so it can't be
+ passed to clients for mmap()
+ <mcsim> antrik: I use vm_allocate in pager_read_page
+ <antrik> mcsim: well, that means that you have to actually implement a
+ pager yourself
+ <antrik> also, when the kernel asks the pager to write back some pages, it
+ expects the memory to become free. if you are "paging" to ordinary
+ anonymous memory, this doesn't happen; so I expect it to have a very bad
+ effect on system performance
+ <antrik> both can be avoided by just passing a real anonymous memory
+ object, i.e. one provided by the defpager
+ <antrik> only problem is that the current defpager implementation can't
+ really handle that...
+ <antrik> at least that's my understanding of the situation