aboutsummaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/disk_io_performance.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-03-26 01:29:05 +0100
committerThomas Schwinge <thomas@schwinge.name>2011-03-26 01:29:05 +0100
commit2ad64644b9290ed1b63108b01ef63939adba5a93 (patch)
treeffcd63c76d4dc0ecd008f404ce01916c13377f3b /community/gsoc/project_ideas/disk_io_performance.mdwn
parent09cf968b288adad78fcd2717db5643b5b9644b84 (diff)
downloadweb-2ad64644b9290ed1b63108b01ef63939adba5a93.tar.gz
web-2ad64644b9290ed1b63108b01ef63939adba5a93.tar.bz2
web-2ad64644b9290ed1b63108b01ef63939adba5a93.zip
Re-integrate GSoC pages with the non-GSoC world.
Remove duplicates, apart from procfs, which should rather be removed from the GSoC items.
Diffstat (limited to 'community/gsoc/project_ideas/disk_io_performance.mdwn')
-rw-r--r--community/gsoc/project_ideas/disk_io_performance.mdwn10
1 files changed, 6 insertions, 4 deletions
diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
index b6f223c8..ae634709 100644
--- a/community/gsoc/project_ideas/disk_io_performance.mdwn
+++ b/community/gsoc/project_ideas/disk_io_performance.mdwn
@@ -11,6 +11,8 @@ License|/fdl]]."]]"""]]
[[!meta title="Disk I/O Performance Tuning"]]
+[[!tag open_issue_hurd]]
+
The most obvious reason for the Hurd feeling slow compared to mainstream
systems like GNU/Linux, is a low I/O system performance, in particular very
slow hard disk access.
@@ -18,8 +20,8 @@ slow hard disk access.
The reason for this slowness is lack and/or bad implementation of common
optimization techniques, like scheduling reads and writes to minimize head
movement; effective block caching; effective reads/writes to partial blocks;
-[[reading/writing multiple blocks at once|clustered_page_faults]]; and
-[[read-ahead]]. The
+[[reading/writing multiple blocks at once|open_issues/performance/io_system/clustered_page_faults]]; and
+[[open_issues/performance/io_system/read-ahead]]. The
[[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
optimizations at a higher logical level.
@@ -29,12 +31,12 @@ requires understanding the data flow through the various layers involved in
disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
[[pager|hurd/libpager]], driver), and general experience with
optimizing complex systems. That said, the killing feature we are definitely
-missing is the [[read-ahead]], and even a very simple implementation would bring
+missing is the [[open_issues/performance/io_system/read-ahead]], and even a very simple implementation would bring
very big performance speedups.
Here are some real testcases:
- * [[binutils_ld_64ksec]];
+ * [[open_issues/performance/io_system/binutils_ld_64ksec]];
* running the Git testsuite which is mostly I/O bound;