rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 260 deletions

diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
deleted file mode 100644
index 64b245f2..00000000
--- a/open_issues/performance.mdwn
+++ /dev/null
@@ -1,260 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 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]]."]]"""]]
-
-*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia
-article"]]) deals with analyzing how computing resources are used for
-completing a specified task.
-
-[[Profiling]] is one relevant tool.
-
-In [[microkernel]]-based systems, there is generally a considerable [[RPC]]
-overhead.
-
-In a multi-server system, it is non-trivial to implement a high-performance
-[[I/O System|community/gsoc/project_ideas/disk_io_performance]].
-
-When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an
-environemnt that doesn't natively implement these interfaces, there may be a
-severe performance degradation.  For example, in this [[`fork` system
-call|/glibc/fork]]'s case.
-
-[[Unit_testing]] can be used for tracking performance regressions.
-
----
-
-  * [[Degradation]]
-
-  * [[fork]]
-
-  * [[IPC_virtual_copy]]
-
-  * [[microbenchmarks]]
-
-  * [[microkernel_multi-server]]
-
-  * [[gnumach_page_cache_policy]]
-
-  * [[metadata_caching]]
-
-  * [[community/gsoc/project_ideas/object_lookups]]
-
----
-
-
-# IRC, freenode, #hurd, 2012-07-05
-
-    <braunr> the more i study the code, the more i think a lot of time is
-      wasted on cpu, unlike the common belief of the lack of performance being
-      only due to I/O
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> there are several kinds of scalability issues
-    <braunr> iirc, i found some big locks in core libraries like libpager and
-      libdiskfs
-    <braunr> but anyway we can live with those
-    <braunr> in the case i observed, ext2fs, relying on libdiskfs and libpager,
-      scans the entire file list to ask for writebacks, as it can't know if the
-      pages are dirty or not
-    <braunr> the mistake here is moving part of the pageout policy out of the
-      kernel
-    <braunr> so it would require the kernel to handle periodic synces of the
-      page cache
-    <antrik> braunr: as for big locks: considering that we don't have any SMP
-      so far, does it really matter?...
-    <braunr> antrik: yes
-    <braunr> we have multithreading
-    <braunr> there is no reason to block many threads while if most of them
-      could continue
-    <braunr> -while
-    <antrik> so that's more about latency than throughput?
-    <braunr> considering sleeping/waking is expensive, it's also about
-      throughput
-    <braunr> currently, everything that deals with sleepable locks (both
-      gnumach and the hurd) just wake every thread waiting for an event when
-      the event occurs (there are a few exceptions, but not many)
-    <antrik> ouch
-
-
-## [[!message-id "20121202101508.GA30541@mail.sceen.net"]]
-
-
-## IRC, freenode, #hurd, 2012-12-04
-
-    <damo22> why do some people think hurd is slow? i find it works well even
-      under heavy load inside a virtual machine
-    <braunr> damo22: the virtual machine actually assists the hurd a lot :p
-    <braunr> but even with that, the hurd is a slow system
-    <damo22> i would have thought it would have the potential to be very fast,
-      considering the model of the kernel
-    <braunr> the design implies by definition more overhead, but the true cause
-      is more than 15 years without optimization on the core components
-    <braunr> how so ?
-    <damo22> since there are less layers of code between the hardware bare
-      metal and the application that users run
-    <braunr> how so ? :)
-    <braunr> it's the contrary actually
-    <damo22> VFS -> IPC -> scheduler -> device drivers -> hardware
-    <damo22> that is monolithic
-    <braunr> well, it's not really meaningful
-    <braunr> and i'd say the same applies for a microkernel system
-    <damo22> if the application can talk directly to hardware through the
-      kernel its almost like plugging directly into the hardware
-    <braunr> you never talk directly to hardware
-    <braunr> you talk to servers instead of the kernel
-    <damo22> ah
-    <braunr> consider monolithic kernel systems like systems with one big
-      server
-    <braunr> the kernel
-    <braunr> whereas a multiserver system is a kernel and many servers
-    <braunr> you still need the VFS to identify your service (and thus your
-      server)
-    <braunr> you need much more IPC, since system calls are "replaced" with RPC
-    <braunr> the scheduler is basically the same
-    <damo22> okay
-    <braunr> device drivers are similar too, except they run in thread context
-      (which is usually a bit heavier)
-    <damo22> but you can do cool things like report when an interrupt line is
-      blocked
-    <braunr> and there are many context switches between all that
-    <braunr> you can do all that in a monolithic kernel too, and faster
-    <braunr> but it's far more elegant, and (when well done) easy to do on a
-      microkernel based system
-    <damo22> yes
-    <damo22> i like elegant, makes coding easier if you know the basics
-    <braunr> there are only two major differences between a monolilthic kernel
-      and a multiserver microkernel system
-    * damo22 listens
-    <braunr> 1/ independence of location (your resources could be anywhere)
-    <braunr> 2/ separation of address spaces (your servers have their own
-      addresses)
-    <damo22> wow
-    <braunr> these both imply additional layers of indirection, making the
-      system as a whole slower
-    <damo22> but it would be far more secure though i suspect
-    <braunr> yes
-    <braunr> and reliable
-    <braunr> that's why systems like qnx were usually adopted for critical
-      tasks
-    <damo22> security and reliability are very important, i would switch to the
-      hurd if it supported all the hardware i use 
-    <braunr> so would i :)
-    <braunr> but performance matters too
-    <damo22> not to me
-    <braunr> it should :p
-    <braunr> it really does matter a lot in practice
-    <damo22> i mean, a 2x slowdown compared to linux would not affect me
-    <damo22> if it had all the benefits we mentioned above
-    <braunr> but the hurd is really slow for other reasons than its additional
-      layers of indrection unfortunately
-    <damo22> is it because of lack of optimisation in the core code?
-    <braunr> we're working on these issues, but it's not easy and takes a lot
-      of time :p
-    <damo22> like you said
-    <braunr> yes
-    <braunr> and also because of some fundamental design choices related to the
-      microkernel back in the 80s
-    <damo22> what about the darwin system
-    <damo22> it uses a mach kernel?
-    <braunr> yes
-    <damo22> what is stopping someone taking the MIT code from darwin and
-      creating a monster free OS
-    <braunr> what for ?
-    <damo22> because it already has hardware support
-    <damo22> and a mach kernel
-    <braunr> in kernel drivers ?
-    <damo22> it has kernel extensions
-    <damo22> you can do things like kextload module
-    <braunr> first, being a mach kernel doesn't make it compatible or even
-      easily usable with the hurd, the interfaces have evolved independantly
-    <braunr> and second, we really do want more stuff out of the kernel
-    <braunr> drivers in particular
-    <damo22> may i ask why you are very keen to have drivers out of kernel?
-    <braunr> for the same reason we want other system services out of the
-      kernel
-    <braunr> security, reliability, etc..
-    <braunr> ease of debugging
-    <braunr> the ability to restart drivers separately, without restarting the
-      kernel
-    <damo22> i see
-
-
-# IRC, freenode, #hurd, 2012-09-13
-
-{{$news/2011-q2#phoronix-3}}.
-
-    <braunr> the phoronix benchmarks don't actually test the operating system
-      ..
-    <hroi_> braunr: well, at least it tests its ability to run programs for
-      those particular tasks
-    <braunr> exactly, it tests how programs that don't make much use of the
-      operating system run
-    <braunr> well yes, we can run programs :)
-    <pinotree> those are just cpu-taking tasks
-    <hroi_> ok
-    <pinotree> if you do a benchmark with also i/o, you can see how it is
-      (quite) slower on hurd
-    <hroi_> perhaps they should have run 10 of those programs in parallel, that
-      would test the kernel multitasking I suppose
-    <braunr> not even I/O, simply system calls
-    <braunr> no, multitasking is ok on the hurd
-    <braunr> and it's very similar to what is done on other systems, which
-      hasn't changed much for a long time
-    <braunr> (except for multiprocessor)
-    <braunr> true OS benchmarks measure system calls
-    <hroi_> ok, so Im sensing the view that the actual OS kernel architecture
-      dont really make that much difference, good software does
-    <braunr> not at all
-    <braunr> i'm only saying that the phoronix benchmark results are useless
-    <braunr> because they didn't measure the right thing
-    <hroi_> ok
-
-
-# Optimizing Data Structure Layout
-
-## IRC, freenode, #hurd, 2014-01-02
-
-    <braunr> teythoon_: wow, digging into the vm code :)
-    <teythoon_> i discovered pahole and gnumach was a tempting target :)
-    <braunr> never heard of pahole :/
-    <teythoon_> it's nice
-    <teythoon_> braunr: try pahole -C kmem_cache /boot/gnumach
-    <teythoon_> on linux that is. ...
-    <braunr> ok
-    <teythoon_> braunr: http://paste.debian.net/73864/
-    <braunr> very nice
-
-
-## IRC, freenode, #hurd, 2014-01-03
-
-    <braunr> teythoon: pahole is a very handy tool :)
-    <teythoon> yes
-    <teythoon> i especially like how general it is
-
-
-# Measurement
-
-## coulomb
-
-### [[!message-id "87wqghouoc.fsf@schwinge.name"]]
-
-## IRC, freenode, #hurd, 2014-02-27
-
-    <braunr> tschwinge: about your concern with regard to performance
-      measurements, you could run kvm with hugetlbfs and cpuset
-    <braunr> on a machine that provides nested page tables, this makes the
-      virtualization overhead as small as it could be considering the
-      implementatoin
-    <braunr> hugetlbs reduces the overhead of page faults, and also implies
-      locked memory while cpuset isolates the vm from global scheduling
-    <braunr> hugetlbfs*
-    <tschwinge> Thanks, will look into that.