From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn | 129 ++++++++++++++++++++++++++- 1 file changed, 128 insertions(+), 1 deletion(-) (limited to 'hurd/translator/tmpfs') diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index 5228515f..16a23405 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013 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 @@ -270,3 +271,129 @@ See also: [[open_issues/resource_management_problems/pagers]]. only problem is that the current defpager implementation can't really handle that... at least that's my understanding of the situation + + +# IRC, freenode, #hurd, 2013-07-05 + + btw, why does the tmpfs translator have to talk to the pager? + to get more control about how the memory is paged out? + read lot's of irc logs about tmpfs on the wiki, but I couldn't + find the answer to that + teythoon: did you read this? + http://www.gnu.org/software/hurd/hurd/translator/tmpfs/tmpfs_vs_defpager.html + mcsim: I did + teythoon: Last discussion, i think has very good point. + To provide memory objects you should implement pager interface + And if you implement pager interface you are the one who is asked + to write data to backing storage to evict them + But tmpfs doesn't do this + mmm, clients doing mmap... + teythoon: You don't have mmap + teythoon: mmap is implemented on top of mach interface + teythoon: I mean you don't have mmap at this level + mcsim: sure, but that's close enough for me at this point + teythoon: diskfs interface requires implementor to provide a memory + object port (send right) + Guest8183: Why tmpfs requires defpager + how did you get to talk about that ? + I was just asked + Guest8183: it's just so unsettling that tmpfs has to be started + as root :/ + teythoon: why ? + *** Guest8183 (~rbraun@dalaran.sceen.net) is now known as braunr_ + braunr_: b/c starting translators isn't a privileged operation, + and starting a tmpfs translator that doesn't even access any device but + "just" memory shouldn't require any special privileges as well imho + so why is tmpfs not based on say libnetfs? b/c it is used for + d-i and someone (apt?) mmaps stuff? + being libdiskfs-based isn't much the issue, iirc + http://lists.gnu.org/archive/html/bug-hurd/2013-03/msg00014.html + too + teythoon: AFAIK apt uses mmap, yes + teythoon: right + a ramfs is actually tricky to implement well + braunr_: What do you mean under "to implement well"? + as efficiently as possible + i.e. being as close as possible to the page cache for minimum + overhead + braunr: AFAIK ramfs should not use swap partition, so page cache + shouldn't be relevant for it. + i'm talking about a ramfs in general + not the specific linux ramfs + in linux, what they call ramfs is the tiny version of tmpfs that + doesn't use swap + i actually don't like "tmpfs" much + memfs may be more appropriate + anyway + braunr: I see. And do you consider defpager variant as "close as + possible to the page cache"? + not far at least + if we were able to use it for memory obects, it would be nice + but defpager only gets attached to objects when they're evicted + before that, anonymous (or temporary, in mach terminology) objects + have no backing store + this was probably designed without having tmpfs in mind + i wonder if it's possible to create a memory object without a + backing store + what should happen to it if kernel decides to evict it? + it sets the default pager as its backing store and pushes it out + that's how it works now, but you said "create a memory object + without a backing store" + mach can do that + i was wondering if we could do that too from userspace + mach does not evict such objects, unless it bound a defpager to + them + but how can you handle this in userspace? + i mean, create a memory object with a null control port + mcsim: is that clearer ? + suppose you create such object, how kernel will evict it if kernel + does not know who is responsible for eviction of this object? + it does + 16:41 < braunr> it sets the default pager as its backing store and + pushes it out + that's how i intend to do it on x15 at least + but it's much simpler there because uvm provides better separation + between anonymous and file memory + whereas they're much too similar in mach vm + than what the difference between current situation, when you + explicitly invoke defpager to create object and implicit method you + propose? + you don't need a true defpager unless you actually have swap + ok + now I see + it also saves the communication overhead when initializing the + object + thank you + which may be important since we use ramfs for speed mostly + agree + it should also simplify the defpager implementation, since it + would only have a single client, the kernel + which may also be important with regard to global design + one thing which is in my opinion very wrong with mach is that it + may be a client + a well designed distributed system should normally not allow on + component to act as both client and server toward another + i.e. the kernel should only be a server, not a client + and there should be a well designed server hierarchy to avoid + deadlocks + (such as the one we had in libpager because of that) + And how about filesystem? It acts both as server and as client + yes + but not towards the same other component + application -> file system -> kernel + no "<->" + the qnx documentation explains that quite well + let me see if i can find the related description + Basically, I've got your point. And I would rather agree that + kernel should not act as client + mcsim: + http://www.qnx.com/developers/docs/6.4.0/neutrino/sys_arch/ipc.html#Robust + one way to implement that (and qnx does that too) is to make + pagers act as client only + they sleep in the kernel, waiting for a reply + and when the kernel needs to evict something, a reply is sent + (qnx doesn't actually do that for paging, but it's a general idea) + braunr: how hierarchy of senders is enforced? + it's not + developers must take care + same as locking, be careful about it -- cgit v1.3.1