| Message ID | 1497374123-15286-3-git-send-email-axboe@kernel.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Jun 13, 2017, at 11:15 AM, Jens Axboe <axboe@kernel.dk> wrote: > > Signed-off-by: Jens Axboe <axboe@kernel.dk> > --- > 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. Comments inline on each of the patches where this matters. Cheers, Andreas > + > static inline void bio_set_streamid(struct bio *bio, unsigned int stream) > { > bio->bi_stream = stream; > -- > 2.7.4 > Cheers, Andreas
On 06/13/2017 01:07 PM, Andreas Dilger wrote: > On Jun 13, 2017, at 11:15 AM, Jens Axboe <axboe@kernel.dk> wrote: >> >> Signed-off-by: Jens Axboe <axboe@kernel.dk> >> --- >> 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.
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, +}; + static inline void bio_set_streamid(struct bio *bio, unsigned int stream) { bio->bi_stream = stream;
Signed-off-by: Jens Axboe <axboe@kernel.dk> --- include/linux/blk_types.h | 13 +++++++++++++ 1 file changed, 13 insertions(+)