Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [RFC PATCH v2] support ioctl for tunable user request | Date | Thu, 8 Sep 2011 17:47:52 +0200 |
| |
On Tuesday 06 September 2011, Kyungmin Park wrote: > > Would __REQ_GC as a shortcut for garbage collection fit? Right now, > > I also think TUNE is not at all describing what we expect the drive > > to do, but it's hard to come up with a term that is generic enough > > to cover similar concepts in other hardware while still describing > > what the drive does. > No problem to use the REQ_GC. BTW, does it acceptable to GC request? I > hope each devices can do own optimization if REQ_GC is requested, if > no need to these one, just ignore it at driver level.
I would suggest that you specify exactly what you mean with REQ_GC at the point where it is defined, e.g.
/* * REQ_GC -- force garbage collection on the device * * The drive is forced to perform a "garbage collection" on data that it * has recently written. This will keep the device busy within a short * time span (up to 60 seconds) during which its performance may be * significantly reduced. After the garbage collection has finished, * the device is expected to provide optimum write performance again. * * User applications that expect expect high continious write throughput * (such as video recording) should issue a REQ_GC before they start * recording. A system daemon may occasionally call this during times * of relative inactivity in order to improve overall performance. * * Examples for hardware that should support this include * - eMMC 4.6 (background operations) * - SD 3.01 (speed class recording) * - PCIe based SSD * - Shingled Hard drives * * Drivers that does not require or support garbage collection will * silently ignore this request. */
I'm not sure if that's the definition you need, but I think it should be at this level of detail.
Arnd
| |