Re: [PATCH 2/6] libata: Report supported TRIM payload size

[Mark Lord <kernel@teksavvy.com>]

On 10-08-20 01:13 PM, Greg Freemyer wrote:
> On Fri, Aug 20, 2010 at 9:53 AM, Mark Lord<kernel@teksavvy.com>  wrote:
>> On 10-08-20 04:58 AM, Christoph Hellwig wrote:
>>>
>>> On Thu, Aug 19, 2010 at 05:50:11PM -0400, Mark Lord wrote:
>>>>
>>>> On 10-08-19 02:05 PM, Martin K. Petersen wrote:
>>>>>
>>>>> I'm only aware of one drive that currently
>>>>> supports more than 512 bytes of payload and it also caps at 4KB.
>>>>
>>>> SSDs based upon the Indilinx Barefoot controller support
>>>> more or less "infinite" payload for TRIM, with no cap.
>>>> But it predates idword[105], so just has a zero there.
>>>
>>> Is there an easy way to identify them?  If so we could add a quirk
>>> for them if it provides enough benefit.
..
> A whitelist to enable large contiguous range trims via 8 512B-block
> payloads seems useful for those devices that don't support word 105.
> (ie. 4KB payload)
>
> But, I doubt there is enough observable performance advantage to
> justify reworking the internal SCSI-ATA translation mechanism in the
> kernel to handle larger payloads.   Especially if only one or two SSDs
> will accept greater than 4KB of payload to the trim command.
..

Actually, for in-kernel uses, even just a single 512-byte long list
would likely be adequate.  The biggest gains will come from simply
having more than one range per TRIM command issued.

Once we get that, it's diminishing returns for larger and larger lists,
and in-kernel code is unlikely to ever be able to generate lists that long.

But getting started should be easier than folks are making it out to be.
The first step is to have "file deletion" issue multi-range trims for
all extents of the file at once, rather than one range at a time as at present.

That'll be the biggest gain, and shouldn't be too complex to implement.
Especially not after Christoph/Tejun's current barrier rework stuff is in place.