From 219988e74ba30498a1c5d71cf557913a70ccca91 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 3 Oct 2011 20:49:54 +0200 Subject: IRC. --- open_issues/performance/degradation.mdwn | 16 +++++++--- .../io_system/clustered_page_faults.mdwn | 23 ++++++++++++++ open_issues/performance/ipc_virtual_copy.mdwn | 37 ++++++++++++++++++++++ 3 files changed, 72 insertions(+), 4 deletions(-) (limited to 'open_issues/performance') diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn index db759308..8c9a087c 100644 --- a/open_issues/performance/degradation.mdwn +++ b/open_issues/performance/degradation.mdwn @@ -10,8 +10,12 @@ 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) +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# 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 @@ -27,9 +31,8 @@ IRC, freenode, #hurd, 2011-07-23: are some serious fragmentation issues < braunr> antrik: both could be induced by fragmentation ---- -During [[IPC_virtual_copy]] testing: +# During [[IPC_virtual_copy]] testing IRC, freenode, #hurd, 2011-09-02: @@ -38,3 +41,8 @@ IRC, freenode, #hurd, 2011-09-02: 800 fifteen minutes ago) manuel: i observed the same behaviour [...] + + +# IRC, freenode, #hurd, 2011-09-22 + +See [[/open_issues/pagers]], IRC, freenode, #hurd, 2011-09-22. diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn index 9e20f8e1..a3baf30d 100644 --- a/open_issues/performance/io_system/clustered_page_faults.mdwn +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -137,3 +137,26 @@ License|/fdl]]."]]"""]] where the pager interface needs to be modified, not the Mach one?... antrik: would be nice wouldn't it ? :) antrik: more probably the page fault handler + + +# IRC, freenode, #hurd, 2011-09-28 + + antrik: I've just recovered part of my old multipage I/O work + antrik: I intend to clean and submit it after finishing the changes + to the pageout system. + slpz: oh, great! + didn't know you worked on multipage I/O + slpz: BTW, have you checked whether any of the work done for GSoC + last year is any good?... + (apart from missing copyright assignments, which would be a + serious problem for the Hurd parts...) + antrik: It was seven years ago, but I did: + http://www.mail-archive.com/bug-hurd@gnu.org/msg10285.html :-) + antrik: Sincerely, I don't think the quality of that code is good + enough to be considered... but I think it was my fault as his mentor for + not correcting him soon enough... + slpz: I see + TBH, I feel guilty myself, for not asking about the situation + immediately when he stopped attending meetings... + slpz: oh, you even already looked into vm_pageout_scan() back then + :-) diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn index 00fa7180..9708ab96 100644 --- a/open_issues/performance/ipc_virtual_copy.mdwn +++ b/open_issues/performance/ipc_virtual_copy.mdwn @@ -356,3 +356,40 @@ IRC, freenode, #hurd, 2011-09-06: in PV it does not make sense: the guest already provides the translated page table which is just faster than anything else + +IRC, freenode, #hurd, 2011-09-09: + + oh BTW, for another data point: dd zero->null gets around 225 MB/s + on my lowly 1 GHz Pentium3, with a blocksize of 32k + (but only half of that with 256k blocksize, and even less with 1M) + the system has been up for a while... don't know whether it's + faster on a freshly booted one + +IRC, freenode, #hurd, 2011-09-15: + + + http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/ + so is the dd command pointed to by that article a measure of io + performance? + sudoman: no, not really + it's basically the baseline of what is possible -- but the actual + slowness we experience is more due to very unoptimal disk access patterns + though using KVM with writeback caching does actually help with + that... + also note that the title of this post really makes no + sense... nested page tables should provide similar improvements for *any* + guest system doing VM manipulation -- it's not Hurd-specific at all + ok, that makes sense. thanks :) + +IRC, freenode, #hurd, 2011-09-16: + + antrik: I wrote that article (the one about How AMD/Intel fixed...) + antrik: It's obviously a bit of an exaggeration, but it's true that + nested pages supposes a great improvement in the performance of Hurd + running on virtual machines + antrik: and it's Hurd specific, as this system is more affected by + the cost of page faults + antrik: and as the impact of virtualization on the performance is + much higher than (almost) any other OS. + antrik: also, dd from /dev/zero to /dev/null it's a measure on how + fast OOL IPC is. -- cgit v1.2.3