public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@fb.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>,
	"Jason B. Akers" <jason.b.akers@intel.com>
Cc: <linux-ide@vger.kernel.org>, <dan.j.williams@intel.com>,
	<kapil.karkra@intel.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives
Date: Wed, 29 Oct 2014 20:35:33 -0600	[thread overview]
Message-ID: <5451A3F5.9020903@fb.com> (raw)
In-Reply-To: <yq1k33il3b3.fsf@sermon.lab.mkp.net>

On 2014-10-29 20:05, Martin K. Petersen wrote:
>>>>>> "Jason" == Jason B Akers <jason.b.akers@intel.com> writes:
>
> Jason> The following series enables the use of Solid State hybrid drives
> Jason> ATA standard 3.2 defines the hybrid information feature, which
> Jason> provides a means for the host driver to provide hints to the
> Jason> SSHDs to guide what to place on the SSD/NAND portion and what to
> Jason> place on the magnetic media.
>
> I have been ripping my hair out in this department for a while.
>
> A colleague and I presented our findings at SNIA SDC a few weeks
> ago. I'm trying to find out if there's an embargo on the slides or if I
> can post them.
>
> First of all I completely agree with Dave's comments about hooking into
> fadvise()/madvise().

The problem with xadvise() is that it handles only one part of this - it 
handles the case of tying some sort of IO related priority information 
to an inode. It does not handle the case of different parts of the file, 
at least not without adding specific extra tracking for this on the 
kernel side.

I think we've needed a proper API for passing in appropriate hints on a 
per-io basis for a LONG time.

> My challenge with hints has been trying to bridge all the various
> existing approaches with the new stuff that's coming down the pipe in
> T10/T13 (LBMD hints) and NFS v4.2 ditto. That turned into a huge mapping
> table as well as a few amendments to what's currently being worked on in
> the standards bodies.

That is the big challenge. We've tried (and failed) in the past to 
define a set of hints that make sense. It'd be a shame to add something 
that's specific to a given transport/technology. That said, this set of 
hints do seem pretty basic and would not necessarily be a bad place to 
start. But they are still very specific to this use case. And who knows 
what will happen on the device side. I might assume that WILLNEED is the 
same as HOT, and that DONTNEED is the same as cold. And then 
applications get upset when vendor X and Y treat them somewhat 
differently, because that's how it fit into their architecture.

This is the primary reason that hints never happened previously.

-- 
Jens Axboe


  reply	other threads:[~2014-10-30  2:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-29 18:23 [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives Jason B. Akers
2014-10-29 18:23 ` [RFC PATCH 1/5] block, ioprio: include caching advice via ionice Jason B. Akers
2014-10-29 19:02   ` Jeff Moyer
2014-10-29 21:07     ` Dan Williams
2014-10-29 18:23 ` [RFC PATCH 2/5] block: ioprio hint to low-level device drivers Jason B. Akers
2014-10-29 18:23 ` [RFC PATCH 3/5] block: untangle ioprio from BLK_CGROUP and BLK_DEV_THROTTLING Jason B. Akers
2014-10-29 18:24 ` [RFC PATCH 4/5] block, mm: Added the necessary plumbing to take ioprio hints down to block layer Jason B. Akers
2014-10-29 18:24 ` [RFC PATCH 5/5] libata: Enabling Solid State Hybrid Drives (SSHDs) based on SATA 3.2 standard Jason B. Akers
2014-10-29 20:14 ` [RFC PATCH 0/5] Enable use of Solid State Hybrid Drives Dave Chinner
2014-10-29 21:10   ` Jens Axboe
2014-10-29 22:09     ` Dave Chinner
2014-10-29 22:24       ` Dan Williams
2014-10-30  7:21         ` Dave Chinner
2014-10-30 14:15           ` Jens Axboe
2014-10-30 17:07           ` Dan Williams
2014-11-10  4:22             ` Dave Chinner
2014-11-12 16:47               ` Dan Williams
2014-10-29 22:49       ` Jens Axboe
2014-10-29 21:11   ` Dan Williams
2014-12-03 15:25   ` Pavel Machek
2014-10-30  2:05 ` Martin K. Petersen
2014-10-30  2:35   ` Jens Axboe [this message]
2014-10-30  3:28     ` Martin K. Petersen
2014-10-30  4:19       ` Dan Williams
2014-10-30 14:17         ` Jens Axboe
2014-10-30 14:53       ` Jens Axboe
2014-10-30 16:27         ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5451A3F5.9020903@fb.com \
    --to=axboe@fb.com \
    --cc=dan.j.williams@intel.com \
    --cc=jason.b.akers@intel.com \
    --cc=kapil.karkra@intel.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox