diff options
Diffstat (limited to 'open_issues/performance')
| -rw-r--r-- | open_issues/performance/io_system/binutils_ld_64ksec.mdwn | 23 | ||||
| -rw-r--r-- | open_issues/performance/io_system/test-lseek.c | 17 | ||||
| -rw-r--r-- | open_issues/performance/io_system/test-mach.c | 19 |
3 files changed, 3 insertions, 56 deletions
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index d0b8ea7f..931fd0ee 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -27,10 +27,6 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. On the idle grubber, this one repeatedly takes a few minutes wall time to complete successfully, contrary to a few seconds on a GNU/Linux system. -> On order of slowness may in fact be due to a Xen-specific issue, see -> [[xen_lseek]]. (But there are probably still one or two orders left, even -> without Xen.) - While processing the object files, there is heavy interaction with the relevant [[hurd/translator/ext2fs]] process. Running [[hurd/debugging/rpctrace]] on the testee shows that (primarily) an ever-repeating series of `io_seek` and @@ -38,19 +34,6 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and 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 - -Also see testcase [[test-lseek.c]] and [[test-mach.c]] - -[[!tag open_issue_xen]] +As Samuel figured out later, this slowness may in fact be due to a Xen-specific +issue, see [[Xen_lseek]]. After the latter has been addressed, we can +re-evaluate this issue here. diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c deleted file mode 100644 index 667dce66..00000000 --- a/open_issues/performance/io_system/test-lseek.c +++ /dev/null @@ -1,17 +0,0 @@ -#include <stdio.h> -#include <math.h> -#include <fcntl.h> -#include <unistd.h> -#include <sys/time.h> -#define N 100000 -int main(void) { - int fd = open("test.c", O_RDONLY); - struct timeval tv1, tv2; - int i; - gettimeofday(&tv1, NULL); - for (i = 0; i < N; i++) - lseek(fd, 0, SEEK_CUR); - gettimeofday(&tv2, NULL); - printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); - return 0; -} diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c deleted file mode 100644 index 90337346..00000000 --- a/open_issues/performance/io_system/test-mach.c +++ /dev/null @@ -1,19 +0,0 @@ -#define _GNU_SOURCE -#include <stdio.h> -#include <fcntl.h> -#include <mach/mach.h> -#define N 1000000 -int main(void) { - struct timeval tv1, tv2; - int i; - task_t task; - task = mach_task_self(); - mach_port_urefs_t refs; - gettimeofday(&tv1, NULL); - for (i = 0; i < N; i++) { - mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs); - } - gettimeofday(&tv2, NULL); - printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); - return 0; -} |