Merge remote-tracking branch 'fp/master'

1 files changed, 113 insertions, 2 deletions

diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
index f0eb473c..ecebe662 100644
--- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -8,9 +8,10 @@ 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_hurd]]
+[[!tag open_issue_gnumach open_issue_hurd]]
 
-\#hurd, freenode, 2010
+
+# IRC, freenode, #hurd, 2010
 
     <slpz> humm... why does tmpfs try to use the default pager? that's a bad
       idea, and probably will never work correctly...
@@ -120,3 +121,113 @@ License|/fdl]]."]]"""]]
       memory, gives them a reference to the default pager by calling
       vm_object_pager_create
     <slpz> this is not really important, but worth noting ;-)
+
+
+# IRC, freenode, #hurd, 2011-09-28
+
+    <slpz> mcsim: "Fix tmpfs" task should be called "Fix default pager" :-)
+    <slpz> mcsim: I've been thinking about modifying tmpfs to actually have
+      it's own storeio based backend, even if a tmpfs with storage sounds a bit
+      stupid.
+    <slpz> mcsim: but I don't like the idea of having translators messing up
+      with the default pager...
+    <antrik> slpz: messing up?...
+    <slpz> antrik: in the sense of creating a number of arbitrarily sized
+      objects
+    <antrik> slpz: well, it doesn't really matter much whether a process
+      indirectly eats up arbitrary amounts of swap through tmpfs, or directly
+      through vm_allocate()...
+    <antrik> though admittedly it's harder to implement resource limits with
+      tmpfs
+    <slpz> antrik: but I've talked about having its own storeio device as
+      backend. This way Mach can pageout memory to tmpfs if it's needed.
+    <mcsim> Do I understand correctly that the goal of tmpfs task is to create
+      tmpfs in RAM?
+    <slpz> mcsim: It is. But it also needs some kind of backend, just in case
+      it's ordered to page out data to free some system's memory.
+    <slpz> mcsim: Nowadays, this backend is another translator that acts as
+      default pager for the whole system
+    <antrik> slpz: pageout memory to tmpfs? not sure what you mean
+    <slpz> antrik: I mean tmpfs acting as its own pager
+    <antrik> slpz: you mean tmpfs not using the swap partition, but some other
+      backing store?
+    <slpz> antrik: Yes.
+
+See also: [[open_issues/resource_management_problems/pagers]].
+
+    <antrik> slpz: I don't think an extra backing store for tmpfs is a good
+      idea. the whole point of tmpfs is not having a backing store... TBH, I'd
+      even like to see a single backing store for anonymous memory and named
+      files
+    <slpz> antrik: But you need a backing store, even if it's the default pager
+      :-)
+    <slpz> antrik: The question is, Should users share the same backing store
+      (swap space) or provide their own?
+    <antrik> slpz: not sure what you mean by "users" in this context :-)
+    <slpz> antrik: Real users with the ability of setting tmpfs translators
+    <antrik> essentially, I'd like to have a single partition that contains
+      both swap space and the main filesystem (at least /tmp, but probably also
+      all of /run, and possibly even /home...)
+    <antrik> but that's a bit off-topic :-)
+    <antrik> well, ideally all storage should be accounted to a user,
+      regardless whether it's swapped out anonymous storage, temporary named
+      files, or permanent files
+    <slpz> antrik: you could use a file as backend for tmpfs
+    <antrik> slpz: what's the point of using tmpfs then? :-)
+    <pinotree> (and then store the file in another tmpfs)
+    <slpz> antrik: mach-defpager could be modified to use storeio instead of
+      Mach's device_* operations, but by the way things work right now, that
+      could be dangerous, IMHO
+    <antrik> pinotree: hehe
+    <pinotree> .. recursive tmpfs'es ;)
+    <antrik> slpz: hm, sounds interesting
+    <slpz> antrik: tmpfs would try to keep data in memory always it's possible
+      (not calling m_o_lock_request would do the trick), but if memory is
+      scarce an Mach starts paging out, it would write it to that
+      file/device/whatever
+    <antrik> ideally, all storage used by system tasks for swapped out
+      anonymous memory as well as temporary named files would end up on the
+      /run partition; while all storage used by users would end up in /home/*
+    <antrik> if users share a partition, some explicit storage accounting would
+      be useful too...
+    <antrik> slpz: is that any different from what "normal" filesystems do?...
+    <antrik> (and *should* it be different?...)
+    <slpz> antrik: Yes, as most FS try to synchronize to disk at a reasonable
+      rate, to prevent data losses.
+    <slpz> antrik: tmpfs would be a FS that wouldn't synchronize until it's
+      forced to do that (which, by the way, it's what's currently happening
+      with everyone that uses the default pager).
+    <antrik> slpz: hm, good point...
+    <slpz> antrik: Also, metadata in never written to disk, only kept in memory
+      (which saves a lot of I/O, too).
+    <slpz> antrik: In fact, we would be doing the same as every other kernel
+      does, but doing it explicitly :-)
+    <antrik> I see the use in separating precious data (in permanent named
+      files) from temporary state (anonymous memory and temporary named files)
+      -- but I'm not sure whether having a completely separate FS for the
+      temporary data is the right approach for that...
+    <slpz> antrik: And giving the user the option to specify its own storage,
+      so we don't limit him to the size established for swap by the super-user.
+    <antrik> either way, that would be a rather radical change... still would
+      be good to fix tmpfs as it is first if possible
+    <antrik> as for limited swap, that's precisely why I'd prefer not to have
+      an extra swap partition at all...
+    <slpz> antrik: It's not much o fa change, it's how it works right now, with
+      the exception of replacing the default pager with its own.
+    <slpz> antrik: I think it's just a matter of 10-20 hours, as
+      much. Including testing.
+    <slpz> antrik: It could be forked with another name, though :-)
+    <antrik> slpz: I don't mean radical change in the implementation... but a
+      radical change in the way it would be used
+    <slpz> antrik: I suggest "almosttmpfs" as the name for the forked one :-P
+    <antrik> hehe
+    <antrik> how about lazyfs?
+    <slpz> antrik: That sound good to me, but probably we should use a more
+      descriptive name :-)
+
+
+## 2011-09-29
+
+    <tschwinge> slpz, antrik: There is a defpager in the Hurd code.  It is not
+      currently being used, and likely incomplete.  It is backed by libstore.
+      I have never looked at it.