manual merge

2 files changed, 371 insertions, 0 deletions

diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn
new file mode 100644
index 00000000..113b965a
--- /dev/null
+++ b/open_issues/resource_management_problems/io_accounting.mdwn
@@ -0,0 +1,49 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+IRC, freenode, #hurd, 2011-07-22
+
+    <braunr> an interesting question i've had in mind for a few weeks now is
+      I/O accounting
+    <braunr> what *is* I/O on a microkernel based system ?
+    <braunr> can any cross address space transfer be classified as I/O ?
+
+IRC, freenode, #hurd, 2011-07-29
+
+    < braunr> how does the hurd account I/O ?
+    < youpi> I don't think it does
+    < youpi> not an easy task, actually
+    < youpi> since gnumach has no idea about it
+    < braunr> yes
+    < braunr> another centralization issue
+    < braunr> does network access count as I/O on linux ?
+    < youpi> no
+    < braunr> not even nfs ?
+    < youpi> else you'd get 100% for servers :)
+    < braunr> right
+    < youpi> nfs goes through vfs first
+    < braunr> i'll rephrase my question
+    < youpi> I'd need to check but I believe it can check nfs
+    < braunr> does I/O accounting occur at the vfs level or block layer ?
+    < youpi> I don't know, but I beleive vfs
+    < youpi> (at least that's how I'd do it)
+    < braunr> i don't have any more nfs box to test that :/
+    < braunr> personally i'd do it at the block layer :)
+    < youpi> well, both
+    < youpi> so e2fsck can show up too
+    < braunr> yes
+    < youpi> it's just a matter of ref counting
+    < youpi> apparently nfs doesn't account
+    < youpi> find . -printf "" doesn't show up in waitio
+    < braunr> good
+    < youpi> well, depends on the point of view
+    < youpi> as a user, you'd like to know whether your processes are stuck on
+      i/o (be it disk or net)
+    < braunr> this implies clearly defining what io is
diff --git a/open_issues/resource_management_problems/pagers.mdwn b/open_issues/resource_management_problems/pagers.mdwn
new file mode 100644
index 00000000..4c36703c
--- /dev/null
+++ b/open_issues/resource_management_problems/pagers.mdwn
@@ -0,0 +1,322 @@
+[[!meta copyright="Copyright © 2011 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_gnumach]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-09-14
+
+Coming from [[translators_set_up_by_untrusted_users]], 2011-09-14 discussion:
+
+    <slpz> antrik: I think a tunable option for preventing non-root users from
+      creating pagers and attaching translators could also be desirable
+    <antrik> slpz: why would you want to prevent creating pagers and attaching
+      translators?
+    <tschwinge> Preventing resource exhaustion, I guess.
+    <slpz> antrik: security and (as tschwinge says) for prevent a rouge pager
+      from exhausting the system.
+    <slpz> antrik: without the ability to use translators for non-root users,
+      Hurd can provide (almost) the same level of resource protection than
+      other *nixes
+
+See also: [[translators_set_up_by_untrusted_users]],
+[[hurd/translator/tmpfs/tmpfs_vs_defpager]].
+
+    <braunr> the hurd is about that though
+    <slpz> there should be also a limit on the number of outstanding requests
+      that a task can have, and some other easily traceable values
+    <braunr> port messages queues have limits
+    <antrik> slpz: anything can exhaust the system. there are much more basic
+      limits that are missing... and I don't see how translators or pagers are
+      special in that regard
+    <slpz> braunr: that's what I said tunable. If I don't share my computer
+      with untrusted users, I want full functionality. Otherwise, I can enable
+      that limitation
+    <slpz> braunr: but I think those limits are on reception
+    <braunr> that's a wrong solution
+    <slpz> antrik: because pagers are external memory objects, and those are
+      treated differently
+    <braunr> compared to what ?
+    <braunr> and yes, the limit is on the message queue, on reception
+    <braunr> why is that a problem ?
+    <slpz> antrik: forbidding the use of translator was for security, to avoid
+      the problem of traversing an untrusted FS
+    <slpz> braunr: compared to anonymous memory
+    <slpz> braunr: because if the limit is on reception, a task can easily do a
+      DoS against a server
+    <braunr> hm actually, the problems we have with swap handling is that
+      anonymous memory is handled in a very similar way as other objects
+    <slpz> braunr: I want to limit the number of outstanding (unprocessed
+      messages in queues) requests
+    <braunr> slpz: the solution isn't about forbidding the use of translators,
+      but changing common code (libc i guess) not to use them, they can still
+      run beside
+    <slpz> braunr: that's because, currently, the external page limit is not
+      enforced
+    <braunr> i'm also not sure about DoS attacks
+    <braunr> if i'm right, there is often one port for each managed object,
+      which usually exist per client
+    <slpz> braunr: yes, that could an option too (for translators, not for
+      pagers)
+    <braunr> i don't see how pagers wouldn't be translators on the hurd
+    <slpz> braunr: all pagers are translators, but not all translators are
+      pagers ;-)
+    <braunr> so if it works for translators, it also works for pagers
+    <slpz> braunr: it would fix the security issue, but not the resource
+      exhaustion problem, with only affects to pagers
+    <braunr> i just don't see a point in implementing resource limits before
+      even fixing other fundamental issues
+    <braunr> the only way to avoid resource exhaustion is resource limits
+    <antrik> slpz: just not following untrusted translators is much more useful
+      than forbidding them alltogether
+    <braunr> and the main problem of mach is resource accounting
+    <braunr> so first, fix that, using the critique as a starting point
+
+[[hurd/critique]].
+
+    <slpz> braunr: i'm not saying that this should be implemented right now,
+      i'm just pointing out this possibility
+    <braunr> i think we're all mostly aware of it
+    <slpz> braunr: resource accounting, as it's expressed in the critique,
+      would be wonderful, but it's just too complex IMHO
+    <braunr> it requires carefully designed changes to the interface yes
+    <slpz> to the interface, to the internals, to user space tasks...
+    <braunr> the internals wouldn't be impacted that much
+    <braunr> user space tasks would mostly include hurd servers
+    <braunr> if the changes are centralized in libraries, it should be easy to
+      provide to the servers
+
+
+# IRC, freenode, #hurd, 2011-09-22
+
+    <slpz> antrik: I've also implemented a simple resource control on dirty
+      pages and changed pageout_scan to free external pages, and only touch
+      anonymous memory if it's really needed
+    <slpz> antrik: those combined make the system work better under heavy load
+    <slpz> antrik: 1.5 GB of RAM and another 1.5 GB of swap helps a lot, too
+      :-)
+    <antrik> hm... I'm not sure what these things mean exactly TBH... but I
+      wonder whether some of these could fix the performance degradation (and
+      ultimate crash) I described recently...
+
+[[/open_issues/default_pager]], [[system performance degradation
+(?)|performance/degradation]].
+
+    <antrik> care to explain them to a noob like me?
+    <slpz> probably not. During my tests, I've noticed that, at some points,
+      the system performance starts to degrade, and this doesn't change until
+      it's restarted
+    <slpz> but I wasn't able to create a test case to reproduce the bug...
+    <slpz> antrik: Sure. First, I've changed GNU Mach to:
+    <slpz>  - Classify all pages from data_supply as external, and count them
+      in vm_page_external_count (previously, this variable was always zero)
+
+[[/open_issues/mach_vm_pageout]]
+
+    <slpz>  - Count all pages for which a  data_unlock has been requested as
+      potentially dirty pages
+    <antrik> there is one important bit I forgot to mention in my recent
+      report: one "reliable" way to cause growing swap usage is simply
+      installing a lot of debian packages (e.g. running an apt-get upgrade)
+    <antrik> some other kinds of I/O also seem to have such an effect, but I
+      wasn't able to pinpoint specific situations
+    <slpz>  - Establish a limit on how many potentially dirty pages are
+      allowed. If it's reached, a notification (right now it's just a bogus
+      m_o_data_unlock, to avoid implementing a new RPC) it's sent to the pager
+      which has generated the page fault
+    <slpz>  - Establish a hard limit on those dirt pages. If it's reached,
+      threads asking for a data_unlock are blocked until someone cleans some
+      pages. This should be improved with a forced pageout, if needed.
+    <slpz>  - And finally, in vm_pageout_scan, run over the inactive queue
+      searching for clean, external pages, freeing them. If it's not possible
+      to free enough pages, or if vm_page_external_count is less than 10% of
+      system's memory, the "normal" pageout is used.
+    <slpz> I need to clean up things a little, but I want to send a preliminary
+      patch to bug-hurd ASAP, to have more people testing it.
+    <slpz> antrik: Do you thing that performance degradation can be related
+      with the number of threads of your ext2fs translators?
+    <antrik> slpz: hm... I didn't watch that recently; but in the past, I
+      observe that the thread count is pretty constant after it reaches
+      something like 14000 on heavy load...
+    <antrik> err... wait, 14000 was ports :-)
+    <antrik> I doubt my system would survive 14000 threads ;-)
+    <antrik> don't remember thread count... I guess I should start watching
+      this again
+    <slpz> antrik: I was thinking that 14000 threads sound like a lot :-)
+    <slpz> what I know for sure, is that when operating with large files, the
+      deactivation of all pages of the memory object which is done after every
+      operation really hurts to performance
+    <antrik> right now my root FS has 5100 ports and a mere 71 thread... but
+      then, it's almost freshly booted :-)
+    <slpz> that's why I've just commented that operation in my code, since it's
+      not really needed anymore :-)
+    <slpz> anyway, after submitting all my pending mails to bug-hurd, I'll try
+      to hunt that bug. Sounds funny.
+    <antrik> regarding your explanation, I'm still trying to wrap my head
+      around some of the details. I must admit that I don't remember what
+      data_unlock does... or maybe I never fully understood it
+    <antrik> the limit on dirty pages is global?
+    <slpz> yes, right now it's global
+    <marcusb> I try to find the old discussion of the thread storm stuff
+    <marcusb> there was some concern about deadlocks
+    <slpz> marcusb: yes, because we were talking about putting an static limit
+      for the server threads of a translators
+    <slpz> marcusb: and that was wrong (my fault, I was even dumber back then
+      :-P)
+    <marcusb> oh boy digging in old mail is no fun.  first I see mistakes in my
+      english.  then I see quite complicated pager stuff I don't ever remember
+      touching.  but there is a patch, and it has my name on it
+    <marcusb> I think I lost a couple of the early years of my hurd hacking :)
+    <antrik> hm... I reread the chapter on locking, and it's still above me :-(
+    <marcusb> not sure what you are talking about, but if there are any
+      specific questions...
+    <antrik> marcusb: external pager interface
+
+[[microkernel/mach/external_pager_mechanism]].
+
+    <marcusb> uuuuh ;)
+    <antrik> memory_object_lock_request(), memory_object_lock_completed(),
+      memory_object_data_unlock()
+    <marcusb> is that from the mach manual?
+    <antrik> yes
+    <antrik> I didn't really understand that part when I first read it a couple
+      of years ago, and I still don't understand it now :-(
+    <marcusb> I am sure I didn't understand it either
+    <marcusb> and maybe I missed my window :)
+    <marcusb> let's see
+    <antrik> hehe
+    <antrik> slpz: what exactly do you mean by "the pager which has generated
+      the page fault"?
+    <antrik> marcusb: essentially I'm trying to understand the explanation of
+      the changes slpz did, but there are several bits totally obscure to me
+      :-(
+    <slpz> antrik: when a I/O operation is requested to ext2fs, it maps the
+      object in question to it's own space, and then memcpy's from/to there
+    <slpz> antrik: so the translator (which is also a pager) is the one who
+      generates the page fault
+    <marcusb> yeah
+    <marcusb> antrik: it's important to understand which messages are sent by
+      the kernel to the manager and which are sent the other way
+    <marcusb> if the dest port is memory_object_t, that indicates a msg from
+      kernel to manager.  if it is memory_object_control_t, it's a msg from
+      manager to kernel
+    <slpz> antrik: m_o_lock_request it's used by the pager to "settle" the
+      status of a memory object, m_o_lock_completed is the answer from the
+      kernel when the lock has been completed (only if the client has requested
+      to be notified), and m_o_data_unlock is a request from the kernel to
+      change the level of protection for a page (it's called from vm_fault.c)
+    <marcusb> slpz: but it's not pagers generating page faults, but users of
+      the memory object on the other side
+    <antrik> marcusb: well, I think the direction is clear to me... but the
+      purpose not really :-)
+    <marcusb> ie a client that mapped a file
+    <slpz> antrik: in ext2fs, all pages are initially provided to the kernel
+      (via data_supply) write protected. When a write operation is done over
+      one of those pages, a page fault it's generated, which sends a
+      m_o_data_unlock to the pager, which answers (if convenient) which a
+      page_lock decreasing the protection level
+    <marcusb> antrik: one use of lock_request is when you want to shut down
+      cleanly and want to get the dirty pages written back to you from the
+      kernel.
+    <marcusb> antrik: the other thing may be COW strategies
+    <slpz> marcusb: well, pagers and clients are in the same task for most
+      translators, like ext2fs
+    <marcusb> slpz: oh.
+    <slpz> marcusb: but yes, a read operation in a mmap'ed file would trigger
+      the fault in a client user task
+    <marcusb> slpz: I think I forgot everything about pagers :)
+    <slpz> marcusb: pager-memcpy.c is the key :-)
+    <marcusb> slpz: what becomes of the fault then?  the kernel sees it's a
+      mapped memory object.  will it then talk to the manager or to a pager? 
+    <antrik> slpz: the translator causes the faults itself when it handles
+      io_read()/io_write() requests I suppose, as opposed to clients accessing
+      mmap()ed objects which then generate the faults?...
+    <antrik> ah, that's actually what you already said above :-)
+    <slpz> marcusb: I'm not sure what do you mean by "manager"...
+    <marcusb> manager == memory object
+    <marcusb> mh
+    <slpz> marcusb: for all external objects, it will ask to their current
+      pager
+    <marcusb> slpz: I think I am missing a couple of details, so nevermind.
+      It's starting to come back to me, but I am a bit afraid of that ;)
+    <marcusb> what I love about the Hurd is how damn readable the code is
+    <marcusb> considering it's an object system, it's so much nicer to read
+      than gtk stuff
+    <slpz> when you get the big picture, it's actually somewhat fun to see how
+      data moves around just to fulfill a simple read()
+    <marcusb> you should make a diagram!
+    <marcusb> bonus point for animated video ;)
+
+[[hurd/IO_path]].
+
+    <slpz> marcusb: heh, take a look at the hurd specific parts of glibc... I
+      cry in pain every time a do that...
+    <marcusb> slpz: oh yeah, rdwr-internal.
+    <marcusb> oh man
+    <marcusb> slpz: funny thing, I just looked at them the other day because of
+      the security issue
+    <slpz> marcusb: I think there was one, maybe a slice from someone's
+      presentation...
+    <marcusb> I think I was always confused about the pager/memobj/kernel
+      interactions
+    <slpz> marcusb: I'm barely able to read Roland's glibc code. I think it's
+      out of my reach.
+    <antrik> marcusb: I think part of the problem is confusing terminology
+    <marcusb> it's good that you are instrumenting the mach kernel to see
+      what's actually going on in there.  it was a black book for me, but neal
+      too a peek and got a much better understanding of the performance issues
+      than I ever did
+    <antrik> when talking about "pager", we usually mean the process doing the
+      paging; but in mach terminology this actually seems to be the "manager",
+      while a "pager" is an individual object in the manager process... or
+      something like that ;-)
+    <marcusb> antrik: I just never took a look at the big picture.  I look at
+      the parts
+    <marcusb> I knew the tail, ears, and legs of the elephant.
+    <marcusb> it's a lot of code for a beginner
+    <antrik> I never understood the distinction between "pager" and "memory
+      object" though...
+    <antrik> maybe "pager" refers to the object in the external pager, while
+      "memory object" is the part managed in Mach itself?...
+    <marcusb> memory object is a real object, to which you can send messages.
+      it's implemented in the server
+    <antrik> hm... maybe it's the other way around then ;-)
+    <marcusb> there is also the default pager
+    <marcusb> I think the pager is just another name for the process that
+      serves the memory object (default pager == memory object for anonymous
+      memory == swap)
+    <marcusb> but!
+    <marcusb> there is also libpager
+
+[[hurd/libpager]]
+
+    <marcusb> and that's a more complicated beast
+    <antrik> actually, the correct term seems to be "default memory manager"...
+    <marcusb> yeah
+    <marcusb> from mach's pov
+    <marcusb> we always called it default pager in the Hurd
+    <antrik> marcusb: problem is that "pager" is sometimes used in the Mach
+      documentation to refer to memory object ports IIRC
+    <marcusb> isn't it defpager executable?
+    <marcusb> could be
+    <marcusb> it's the same thing, really
+    <antrik> indeed, the program implementing the default memory manager is
+      called "default pager"... so the terminology is really inconsistent
+    <marcusb> the hurd's pager library is a high level abstraction for mach's
+      external memory object interface.
+    <marcusb> i wouldn't worry about it too much
+    <antrik> I never looked at libpager
+    <marcusb> you should!
+    <marcusb> it's an important beast
+    <antrik> never seemed relevant to anything I did so far...
+    <antrik> though maybe it would help understanding
+    <marcusb> it's related to what you are looking now :)