Hi Bart,
>On 10/30/23 04:11, Kanchan Joshi wrote:
>> On 10/18/2023 2:17 AM, Bart Van Assche wrote:
>>> +/* Block storage write lifetime hint values. */
>>> +enum rw_hint {
>>> + WRITE_LIFE_NOT_SET = 0, /* RWH_WRITE_LIFE_NOT_SET */
>>> + WRITE_LIFE_NONE = 1, /* RWH_WRITE_LIFE_NONE */
>>> + WRITE_LIFE_SHORT = 2, /* RWH_WRITE_LIFE_SHORT */
>>> + WRITE_LIFE_MEDIUM = 3, /* RWH_WRITE_LIFE_MEDIUM */
>>> + WRITE_LIFE_LONG = 4, /* RWH_WRITE_LIFE_LONG */
>>> + WRITE_LIFE_EXTREME = 5, /* RWH_WRITE_LIFE_EXTREME */
>>> +} __packed;
>>> +
>>> +static_assert(sizeof(enum rw_hint) == 1);
>>
>> Does it make sense to do away with these, and have temperature-neutral
>> names instead e.g., WRITE_LIFE_1, WRITE_LIFE_2?
>>
>> With the current choice:
>> - If the count goes up (beyond 5 hints), infra can scale fine but these
>> names do not. Imagine ULTRA_EXTREME after EXTREME.
>> - Applications or in-kernel users can specify LONG hint with data that
>> actually has a SHORT lifetime. Nothing really ensures that LONG is
>> really LONG.
>>
>> Temperature-neutral names seem more generic/scalable and do not present
>> the unnecessary need to be accurate with relative temperatures.
>
>Thanks for having taken a look at this patch series. Jens asked for data
>that shows that this patch series improves performance. Is this
>something Samsung can help with?
We analyzed the NAND block erase counter with and without stream separation
through a long-term workload in F2FS.
The analysis showed that the erase counter is reduced by approximately 40%
with stream seperation.
Long-term workload is a scenario where erase and write are repeated by
stream after performing precondition fill for each temperature of F2FS.
Thanks,
Daejun.
>
>Thanks,
>
>Bart.
>
>
>
