summaryrefslogtreecommitdiff
path: root/open_issues/performance/io_system
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/performance/io_system')
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn15
1 files changed, 15 insertions, 0 deletions
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]]