summaryrefslogtreecommitdiff
path: root/open_issues/performance
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/performance')
-rw-r--r--open_issues/performance/degradation.mdwn28
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn15
-rw-r--r--open_issues/performance/microkernel_multi-server.mdwn47
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