> -----Original Message----- > From: Matias Bjørling [mailto:m@xxxxxxxxxxx] > Sent: Wednesday, March 25, 2015 1:11 AM > To: Ming Lin-SSI; Jens Axboe; linux-kernel@xxxxxxxxxxxxxxx; linux- > fsdevel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/6] block: add support for carrying a stream ID in a bio > > >> Pushing it higher is not a big deal as far as the implementation > >> goes, though > >> 16 bits might be stealing a bit too much space for this. On 32-bit > >> archs, we have 18 bits currently free that we can abuse. The Samsung > >> device supports > >> 16 streams. That's honestly a lot more than I would expect most > >> devices to support in hardware, 16 is a lot of open erase blocks and write > append points. > >> Obviously the open channel effort would make that more feasible, > though. > > > > Can we use 8 bits at least? I'll test performance with 16 streams. > > > > Ming, can you provide an example of how streams will be managed for > multiple applications? I can see how it would be efficient for a single > application, but how will it be managed for multiple applications? Multiple applications will get different stream-id. For example, Application 1: stream_id = open_stream(NVME_DEVICE_HANDLE, ....); //maybe stream-id 1 fadvise(fd, stream_id, 0, POSIX_FADV_STREAMID); write(fd, buf, count); close_stream(NVME_DEVICE_HANDLE, stream_id); Application 2: stream_id = open_stream(NVME_DEVICE_HANDLE, ....); //maybe stream-id 2 fadvise(fd, stream_id, 0, POSIX_FADV_STREAMID); write(fd, buf, count); close_stream(NVME_DEVICE_HANDLE, stream_id); Thanks, Ming > > -Matias -- 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
