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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 Sep 2011 17:47:52 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Kyungmin Park <kmpark@...radead.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <jaxboe@...ionio.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Lin Ming <lxy@...pku.edu.cn>
Subject: Re: [RFC PATCH v2] support ioctl for tunable user request

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/