On 04/09/2015 04:46 PM, Andreas Dilger wrote:
On Mar 25, 2015, at 9:07 AM, Jens Axboe <axboe@xxxxxx> wrote:
The top bits of bio->bi_flags are reserved for keeping the
allocation pool, set aside the next eight bits for carrying
a stream ID. That leaves us with support for 255 streams,
0 is reserved as a "stream not set" value.
I understand that the stream ID is not related to specific priority
of an IO request. However, I'm wondering how this patch series
interacts with some of the other patch series that add cache priority
hints? Is there a danger of running out of space in the IO pipeline
for the additional cache hints if this is using 8 bits?
That's always a risk, of course, but that goes for most features that
need to carry more data in struct bio (or elsewhere). Otherwise we'll
have to bite the bullet and add a new field.
+/*
+ * after the pool bits, next 8 bits are for the stream id
+ */
+#define BIO_STREAM_BITS (8)
+#define BIO_STREAM_OFFSET (BITS_PER_LONG - 12)
Should this really be:
#define BIO_STREAM_OFFSET (BIO_POOL_OFFSET - BIO_STREAM_BITS)
Otherwise there is a risk of conflict if someone changes BIO_POOL_BITS.
Good point, that would be cleaner. I'll make that change.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
