Re: [RFC PATCH v2] support ioctl for tunable user request

[Arnd Bergmann]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/