rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 77 deletions

diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn
deleted file mode 100644
index eaaa2289..00000000
--- a/open_issues/multiprocessing.mdwn
+++ /dev/null
@@ -1,77 +0,0 @@
-[[!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
-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_hurd]]
-
-We would expect that fine-grained, compartmentalized systems, that is,
-microkernel-based multi-server systems in particular, would be ideal candidates
-for applying multiprocessing.  That is, however, only true from a first and
-inexperienced point of view: there are many difficulties.
-
-
-# IRC, freenode, #hurd, August / September 2010
-
-    <marcusb> silver_hook: because multi-server systems depend on inter-process
-      communication, and inter-process communication is many times more
-      expensive across cpus
-    <marcusb> silver_hook: so you either force interrelated work on the same
-      cpu, or suffer heavy penalties.  and in a typical fine-grained object
-      system, all objects are interconnected!
-    <marcusb> silver_hook: resources in today's systems, even in a single node
-      with one cpu, but more so in a network, are very non-uniform.  scheduling
-      these resources efficiently is a huge problem.  restricting the resource
-      distribution policies in the way microkernel systems tend to do is posing
-      serious research challenges
-
-
-# IRC, freenode, #hurd, 2011-07-26
-
-    < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a
-      multicore architecture than linux ?
-    < braunr> CTKArcher: short answer: no
-    < CTKArcher> it's easier to imagine one server pro core than the linux
-      kernel divided to be executed on multiple cores
-    < braunr> CTKArcher: this approach is less efficient
-    < braunr> CTKArcher: threads carry state, both explicit and implicit (like
-      cache data)
-    < braunr> CTKArcher: switching to another core means resetting and
-      refetching this state
-    < braunr> it's expensive and there is no gain obtained by doing this
-    < braunr> thread migration (having a thread from a client also run in
-      servers when making synchronous RPC, even handling its own page faults)
-      was implemented in mach4 and is imo a very good thing we should have
-    < braunr> CTKArcher: and concerning linux, it's actually very scalable
-    < braunr> it's already like if all client threads run in servers (the
-      kernel is the servers there)
-    < braunr> rcu is used a lot
-    < braunr> thread migration already takes into account smt, cores, and numa
-    < braunr> it's hard to do something better
-    < braunr> (here, thread migration means being dispatched on another cpu)
-
-
-# debian-hurd list
-
-On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote:
-> Georg Lehner writes:
->
-> > - One promise of the microkernel architecture is better performance on
-> >   multiprocessor systems, or multicomputer systems. What is the status
-> >   of Gnu Mach with respect to these.
->
-> This may or may not be true.  The Hurd is built around a microkernel
-> architecture because of its conceptual elegance and flexibility.
-> Other touted advantages may be more illusory than real, at least, they
-> aren't something *we* are proclaiming is our motivation.
-
-
----
-
-See also: [[multithreading]].