On Thu, Oct 30, 2014 at 7:53 AM, Jens Axboe <axboe@xxxxxx> wrote: > On 2014-10-29 21:28, Martin K. Petersen wrote: >> The notion of telling the storage *why* you're doing I/O instead of >> telling it how to manage its cache and where to put stuff is closely >> aligned with our internal experiences with I/O hints over the last >> decade. But it's a bit of a departure from where things are going in the >> standards bodies. In any case I thought it was interesting that pretty >> much every use case that people came up with could be adequately >> described by a handful of I/O classes. > > > Definitely agree on this, it's about notifying storage on what type of IO > this is, or why we are doing it. I'm just still worried that this will then > end up being unusable by applications, since they can't rely on anything. > Say one vendor treats WONTNEED in a much colder fashion than others, the > user/application will then complain about the access latencies for the next > IO to that location. "Yes it's cold, but I didn't expect it to be THAT cold" > and then come to the conclusion that they can't feasibly use these hints as > they don't do exactly what they want. > > It'd be nice if we could augment this with a query interface of some sort, > that could give the application some idea of what happens for each of the > passed in hints. That would improve the situation from a "lets set this hint > and hope it does what we think it does" to a more predictable and robust > environment. > I'm skeptical we (Linux kernel) can ever get this right. If an application wants strict determinism in the meaning of hints it seems it will need to qualify them against component-vendor / platform-vendor provided transport-translation. For this RFC we had consumer platforms in mind where "mostly better than baseline" is the acceptance criteria vs "hard QOS". -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
