On 06/13/2017 01:07 PM, Andreas Dilger wrote:
> On Jun 13, 2017, at 11:15 AM, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>
>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>> ---
>> include/linux/blk_types.h | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
>> index 1940876a7fa7..16c4e657807f 100644
>> --- a/include/linux/blk_types.h
>> +++ b/include/linux/blk_types.h
>> @@ -314,6 +314,19 @@ struct blk_rq_stat {
>> u64 batch;
>> };
>>
>> +/*
>> + * Data life time definitions for writes. These are relative within a
>> + * given device, no absolute meaning is attached to them.
>> + */
>> +enum {
>> + WRITE_LIFE_UNKNOWN = 0,
>> + WRITE_LIFE_SHORT,
>> + WRITE_LIFE_MEDIUM,
>> + WRITE_LIFE_LONG,
>> + WRITE_LIFE_EXTREME,
>> + WRITE_LIFE_NR,
>> +};
>
> With the exception of these enums, there is actually enough space in the
> various structures to pass at least a 4-bit stream ID through the whole
> stack (actually, a full 32-bit stream ID, except for the debugfs stats).
>
> I'm not necessarily against having some pre-defined meanings for these
> values, but with a few trivial changes to the code it would be possible
> to make this functionality much more flexible.
One thing I'm envisioning, down the line, is to have sets of streams. We
have the four streams, should be good enough for any app. But for multiple
apps, it becomes more difficult. So we could essentially shift the stream
ID up and share this space, and also utilize more streams on the back end
for that. For software caching solution, they can already factor in the
application, but for hardware devices, we could make use of that.
So I don't think there's anything wrong with the current approach. The
whole point was not to over-complicate or over-engineer this.
--
Jens Axboe
