Re: about TRIM/DISCARD support and barriers

[Tejun Heo]

Dongjun Shin wrote:
>> So, can you please confirm that, what we eventually get is simple TRIM
>> w/ multiple ranges?  Which, BTW, makes sense as it's something the
>> device can't infer from the access pattern.  Also, if there still is
>> wiggle room, what would be a worthy optimization is to allow TRIM
>> commands to be sent together with other NCQ commands as otherwise the
>> drive will have to drain all other commands to process a TRIM command
>> which will be inefficient.
>>
> 
> AFAIK, only the trim feature of data set management command will be included
> and a single trim may contain multiple ranges. But, it's not possible to send
> non-read/write command during NCQ as specified by the t13(1).

Yeah, I know the scheduling restriction and that's exactly why I was
asking.  To rephrase: I think it would be nice to make TRIM an NCQ
command as it's likely to get mixed with regular IO traffic a lot but
maybe we can schedule it strategically such that it follows FLUSH or the
queue is mostly idle.  Anyways, if someone knows anyone working on this,
please feel free to poke.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/