diff options
| -rw-r--r-- | contributing/web_pages.mdwn | 21 | ||||
| -rw-r--r-- | open_issues/performance/io_system/binutils_ld_64ksec.mdwn | 23 | ||||
| -rw-r--r-- | open_issues/xen_lseek.mdwn | 22 | ||||
| -rw-r--r-- | open_issues/xen_lseek/test-lseek.c (renamed from open_issues/performance/io_system/test-lseek.c) | 0 | ||||
| -rw-r--r-- | open_issues/xen_lseek/test-mach.c (renamed from open_issues/performance/io_system/test-mach.c) | 0 |
5 files changed, 40 insertions, 26 deletions
diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index d1b3c0fc..b2e96121 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -130,13 +130,22 @@ is also read-only. $ git clone http://www.bddebian.com:8888/git/hurd-web [dest] -For all cases: if you omit `[dest]` it will default to `hurd-web`. +Or, you can check out the Savannah repository: -Later, you can just `cd` into the `hurd-web` directory and run a `git pull` to -get hold of the latest changes others have been installing in the mean time. -(In most cases, you should use `git pull --rebase`, -to avoid useless *Merge branch ...* messages. See the -Git documentation for details.) + $ git clone git://git.savannah.gnu.org/hurd/web.git [dest] + +See <http://git.savannah.gnu.org/cgit/hurd/web.git>. If you're using the `ssh` +protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can +also push to this repository. The disadvantage of pushing to the Savannah +repository is that there is no [[ikiwiki]] installation where the pushed +changes are immediatelly rendered and viewable by everyone. + +For all cases: if you omit `[dest]` it will default to `hurd-web` for the +`bddebian.com` repositories, or `web` for a Savannah clone. + +Later, you can just `cd` into the `hurd-web` or `web` directory, and, for +example, run `git pull` to get hold of the latest changes others have been +installing in the mean time. ## Editing the Content 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/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: + + <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 + IRC, freenode, #hurd, 2011-11-02: <youpi> 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: + + <youpi> [test-mach.c is] mostly as a reference for the trap overhead + <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach + <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek + <youpi> that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + <youpi> yes, about 0.5ms for an lseek, that's quite high :) diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/xen_lseek/test-lseek.c index 667dce66..667dce66 100644 --- a/open_issues/performance/io_system/test-lseek.c +++ b/open_issues/xen_lseek/test-lseek.c diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/xen_lseek/test-mach.c index 90337346..90337346 100644 --- a/open_issues/performance/io_system/test-mach.c +++ b/open_issues/xen_lseek/test-mach.c |