IRC.

3 files changed, 90 insertions, 0 deletions

diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn
new file mode 100644
index 00000000..5db82e31
--- /dev/null
+++ b/open_issues/performance/degradation.mdwn
@@ -0,0 +1,28 @@
+[[!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]]."]]"""]]
+
+[[!meta title="Degradation of GNU/Hurd ``system performance''"]]
+
+Email, *id:"87mxg2ahh8.fsf@kepler.schwinge.homeip.net"* (bug-hurd, 2011-07-25,
+Thomas Schwinge)
+
+> Building a certain GCC configuration on a freshly booted system: 11 h.
+> Remove build tree, build it again (2nd): 12 h 50 min.  Huh.  Remove build
+> tree, reboot, build it again (1st): back to 11 h.  Remove build tree, build
+> it again (2nd): 12 h 40 min.  Remove build tree, build it again (3rd): 15 h.
+
+IRC, freenode, #hurd, 2011-07-23
+
+    < antrik> tschwinge: yes, the system definitely gets slower with
+      time. after running for a couple of weeks, it needs at least twice as
+      long to open a new shell for example
+    < antrik> I don't know whether this is only related to swap usage, or there
+      are some serious fragmentation issues
+    < braunr> antrik: both could be induced by fragmentation
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index 79c2300f..359d5fee 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -33,3 +33,18 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and
 `io_read` is being processed.  Running the testee on GNU/Linux with strace
 shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't
 as slow as the Hurd's.
+
+---
+
+IRC, freenode, #hurd, 2011-09-01:
+
+    <youpi> hum, f951 does myriads of   71->io_seek_request (32768 0) = 0 32768
+    <youpi> no wonder it's slow
+    <youpi> unfortunately that's also what it does on linux, the system call is
+      just less costly
+    <youpi> apparently gfortran calls io_seek for, like, every token of the
+      sourced file
+    <youpi> (fgetpos actually, but that's the same)
+    <youpi> and it is indeed about 10 times slower under Xen for some reason
+
+[[!tag open_issue_xen]]
diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn
new file mode 100644
index 00000000..111d2b88
--- /dev/null
+++ b/open_issues/performance/microkernel_multi-server.mdwn
@@ -0,0 +1,47 @@
+[[!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_documentation]]
+
+Performance issues due to the microkernel/multi-server system architecture?
+
+IRC, freenode, #hurd, 2011-07-26
+
+    < CTKArcher> I read that, because of its microkernel+servers design, the
+      hurd was slower than a monolithic kernel, is that confirmed ?
+    < youpi> the hurd is currently slower than current monolithic kernels, but
+      it's not due to the microkernel + servers design
+    < youpi> the microkernel+servers design makes the system call path longer
+    < youpi> but you're bound by disk and network speed
+    < youpi> so the extra overhead will not hurt so much
+    < youpi> except dumb applications keeping doing system calls all the time
+      of course, but they are usually considered bogus
+    < braunr> there may be some patterns (like applications using pipes
+      extensively, e.g. git-svn) which may suffer from the design, but still in
+      an acceptable range
+    < CTKArcher> so, you are saying that disk and network are more slowing the
+      system than the longer system call path and because of that, it wont
+      really matter ?
+    < youpi> braunr: they should sitll be fixed because they'll suffer (even if
+      less) on monolithic kernels
+    < youpi> CTKArcher: yes
+    < braunr> yes
+    < CTKArcher> mmh
+    < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10
+      iirc, about minix
+    < youpi> they even go as far as using an IPC for each low-level in/out
+    < youpi> for security
+    < braunr> this has been expected for a long time
+    < braunr> which is what motivated research in microkernels
+    < CTKArcher> I've already downloaded the video :)
+    < youpi> and it has been more and more true with faster and faster cpus
+    < braunr> but in 95, processors weren't that fast compared to other
+      components as they are now
+    < youpi> while disk/mem haven't evovled so fast