Re: [PATCH 0/11] Add support for write life time hints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 13, 2017, at 12:26 PM, Jens Axboe <axboe@xxxxxxxxx> wrote:
> 
> On 06/13/2017 12:04 PM, Andreas Dilger wrote:
>> On Jun 13, 2017, at 11:15 AM, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>> 
>>> A new iteration of this patchset, previously known as write streams.
>>> Instead of exposing numeric values for streams, I've previously
>>> advocated for just doing a set of hints that makes sense instead. See
>>> the coverage from the LSFMM summit this year:
>>> 
>>> https://lwn.net/Articles/717755/
>>> 
>>> This patchset attempts to do that. We define 4 flags for the pwritev2
>>> system call:
>>> 
>>> RWF_WRITE_LIFE_SHORT	Data written with this flag is expected to have
>>> 			a high overwrite rate, or life time.
>>> 
>>> RWF_WRITE_LIFE_MEDIUM	Longer life time than SHORT
>>> 
>>> RWF_WRITE_LIFE_LONG	Longer life time than MEDIUM
>>> 
>>> RWF_WRITE_LIFE_EXTREME	Longer life time than LONG
>>> 
>>> The idea is that these are relative values, so an application can
>>> use them as they see fit. The underlying device can then place
>>> data appropriately, or be free to ignore the hint. It's just a hint.
>>> 
>>> Comments appreciated.
>> 
>> I thought that one of the major attractions of numeric stream IDs was
>> that they had no semantic meanings, just "N is similar to N" and "M is
>> similar to M", and it is up to userspace to define what these mean?
>> 
>> That allows userspace to use the IDs for lifetimes (as above), but
>> also/instead use them for allocation sizes, different applications,
>> different users, etc.
> 
> Right, that is indeed the intent. But we have to attach some naming
> to them. Userspace could in theory use these totally randomly, and
> things like NVMe would not care. But the semantic meaning of "short"
> vs "long" is important on caching infrastructure where you might
> want to use the hint for data placement.
> 
> I think the important part here is that no absolute meaning is
> attached to them, only relative.

In both IOCB_WRITE_LIFE_* and RWF_WRITE_LIFE_* this is consuming 4 bits of
space (which is itself fine) for only 4 different stream IDs.  Why not just
shift a 4-bit arbitrary stream ID to the appropriate offset in those fields,
rather than treating them as 4 individual bits and allowing only one of
them to be passed down the stack at a time?

Cheers, Andreas





Attachment: signature.asc
Description: Message signed with OpenPGP


[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux