diff --git a/en/projects/ideas/ideas.xml b/en/projects/ideas/ideas.xml
index 83111036ba..e58b49f0ed 100644
--- a/en/projects/ideas/ideas.xml
+++ b/en/projects/ideas/ideas.xml
@@ -15,7 +15,7 @@ Ideas//EN"
Technical contact: Emiliano Mennucci
+ href="mailto:luigi@freebsd.org">Luigi RizzoReferences: The Pluggable Disk Schedulers SoC project, Patches
-Our "Pluggable Disk Schedulers" SoC 2005 project resulted in code which - solved the problem where large sequential I/O requests, or certain - access patterns from one or a few processes, might almost completely - starve other processes. It is available as a patch for RELENG_4 and - RELENG_5. Unfortunately the code in FreeBSD-current (and RELENG_6) - changed too much, so that the patches can not be committed. The goal - of this project is to port the pluggable disk schedulers to the GEOM - framework.
-Interested people should also have a look at - a mail thread about this (Ulf is not working on this) and - further discussion of the corresponding GEOM aspects.
+In a 2005 GSoC project, "Pluggable Disk Schedulers", Emiliano + Mennucci explored the feasibility of pluggable disk schedulers + for FreeBSD. The project was successful, but we could not explore + certain approaches (e.g. "anticipation", where requests are delayed + hoping that some future ones can served without a seek) due to + architectural limitations the kernel had at the time. +
+ Since then, the GEOM infrastructure has become available on FreeBSD + for interacting with disk I/O requests. GEOM has enabled us to + work on disk schedulers in a much more flexible way, allowing a + much faster development of disk scheduling algorithms. With + Fabio Checconi, we have developed a prototype + implementation of some anticipatory schedulers, see + GEOM_SCHED. +
+ GEOM_SCHED works within the geom layer, i.e. above the device driver + where queueing of requests may actually occur. The way GEOM_SCHED + does scheduling is by limiting the number of outstanding requests + to the device, and the performance implications of this approach + need to be measured. An alternative approach is to push the + scheduler (using the same algorithms developed in GEOM_SCHED, + and most likely the same code) within the device drivers. This less general + (as it needs to be replicated in all drivers) but it may be + an interesting thing to do e.g. for some popular device drivers + such as ATA. +
+ The proposed SoC work can address one or more of the following + aspects: + i) implement suitable classifiers for + disk requests; ii) implement techniques for the auto-tuning of + the scheduler parameters; iii) measure the performance implications + of doing scheduling above the device driver, and possibly design + and implement a suitable mechanism to push the GEOM_SCHED + module within the device driver itself. +
+Ultimately, we expect to end up with a production quality subsystem +for use in FreeBSD. +
Requirements: