diff options
author | Thomas Schwinge <thomas@schwinge.name> | 2011-10-03 20:51:38 +0200 |
---|---|---|
committer | Thomas Schwinge <thomas@schwinge.name> | 2011-10-03 20:51:38 +0200 |
commit | 9e35f65d76dd63b05e0260f131e700700de657ee (patch) | |
tree | 0563034d08ceed6bd26fc1dea24098dbc76cf1d1 /open_issues/performance/ipc_virtual_copy.mdwn | |
parent | fd416997c65cb122acc1e6c2b36ff10e781273c7 (diff) | |
parent | 219988e74ba30498a1c5d71cf557913a70ccca91 (diff) |
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'open_issues/performance/ipc_virtual_copy.mdwn')
-rw-r--r-- | open_issues/performance/ipc_virtual_copy.mdwn | 37 |
1 files changed, 37 insertions, 0 deletions
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: <youpi> in PV it does not make sense: the guest already provides the translated page table <youpi> which is just faster than anything else + +IRC, freenode, #hurd, 2011-09-09: + + <antrik> 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 + <antrik> (but only half of that with 256k blocksize, and even less with 1M) + <antrik> 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: + + <sudoman> + http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/ + <sudoman> so is the dd command pointed to by that article a measure of io + performance? + <antrik> sudoman: no, not really + <antrik> it's basically the baseline of what is possible -- but the actual + slowness we experience is more due to very unoptimal disk access patterns + <antrik> though using KVM with writeback caching does actually help with + that... + <antrik> 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 + <sudoman> ok, that makes sense. thanks :) + +IRC, freenode, #hurd, 2011-09-16: + + <slpz> antrik: I wrote that article (the one about How AMD/Intel fixed...) + <slpz> 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 + <slpz> antrik: and it's Hurd specific, as this system is more affected by + the cost of page faults + <slpz> antrik: and as the impact of virtualization on the performance is + much higher than (almost) any other OS. + <slpz> antrik: also, dd from /dev/zero to /dev/null it's a measure on how + fast OOL IPC is. |