From 4cc3f682fb57a920e3cc14e99323d66e380c1ee7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 5 Nov 2011 23:19:34 +0100 Subject: open_issues/performance/io_system/binutils_ld_64ksec: Move Xen lseek stuff... open_issues/xen_lseek: ... here. --- open_issues/xen_lseek.mdwn | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'open_issues/xen_lseek.mdwn') diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn index accc7c8f..756abf5e 100644 --- a/open_issues/xen_lseek.mdwn +++ b/open_issues/xen_lseek.mdwn @@ -10,6 +10,17 @@ License|/fdl]]."]]"""]] [[!tag open_issue_xen]] +IRC, freenode, #hurd, 2011-09-01: + + hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + no wonder it's slow + unfortunately that's also what it does on linux, the system call is + just less costly + apparently gfortran calls io_seek for, like, every token of the + sourced file + (fgetpos actually, but that's the same) + and it is indeed about 10 times slower under Xen for some reason + IRC, freenode, #hurd, 2011-11-02: btw, we have a performance issue with xen @@ -33,3 +44,14 @@ IRC, freenode, #hurd, 2011-11-02: http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html [[performance/io_system/binutils_ld_64ksec]]. + +Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]]. + +IRC, freenode, #hurd, 2011-11-05: + + [test-mach.c is] mostly as a reference for the trap overhead + 0.56µs (xen) vs 0.48µs(kvm) on test-mach + 455µs(xen) vs 16µs(kvm) on test-lseek + that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + yes, about 0.5ms for an lseek, that's quite high :) -- cgit v1.2.3