Re: [PATCH 2/2] ata: libata-scsi: scale DSM TRIM payload by MAX PAGES PER DSM COMMAND

Hannes Reinecke <[email protected]>
Newsgroups org.kernel.vger.linux-ide
Message-ID <[email protected]>
On 7/2/26 12:46 AM, Niklas Cassel wrote:
> DSM TRIM currently always emits a single 512-byte page of LBA Range Entries
> (ATA_MAX_TRIM_RNUM == 64 ranges), regardless of how many pages the device
> can accept in one DATA SET MANAGEMENT command.
> 
> The maximum is reported by MAX PAGES PER DSM COMMAND (IDENTIFY DEVICE word
> 105).  Honour it: size the TRIM descriptor as a whole number of 512-byte
> pages, bounded by that limit and by the logical sector size (the WRITE SAME
> data-out buffer is a single logical block).  Build and transfer only as
> many pages as the request needs, and set the DSM COUNT field, qc->nbytes
> and the maximum WRITE SAME length in the Block Limits VPD page accordingly.
> 
> Build the descriptor straight into the WRITE SAME data-out buffer using an
> atomic sg_miter mapping, instead of staging it in the shared ata_scsi_rbuf
> and copying it out.  This removes the global ata_scsi_rbuf_lock and a
> memcpy from the TRIM path.
> 
> While commit 9379e6b8e0f9 ("libata: Safely overwrite attached page in WRITE
> SAME xlat") replaced direct access to the data-out buffer with an
> intermediate step that writes the entries in the ata_scsi_rbuf buffer, this
> solution writes to the data-out buffer using sg_miter, which maps each
> segment with kmap_atomic (SG_MITER_ATOMIC), so it's highmem- and
> multi-segment-safe, and it's usable from the non-sleeping
> command-submission path (unlike the page_address() access that
> ata_scsi_rbuf originally replaced).
> 
> A 512-byte-sector device still uses a single page, so its behaviour is
> unchanged.
> 
> Add ata_id_dsm_max_pages() to read IDENTIFY DEVICE word 105.
> 
> Signed-off-by: Niklas Cassel <[email protected]>
> ---
>   drivers/ata/libata-scsi.c | 132 ++++++++++++++++++++++++++------------
>   include/linux/ata.h       |  13 ++++
>   2 files changed, 104 insertions(+), 41 deletions(-)
> 
Reviewed-by: Hannes Reinecke <[email protected]>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.