Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 18 Mar 2024 13:05:03 +0000 | Subject | Re: [PATCH 1/1] swiotlb: extend buffer pre-padding to alloc_align_mask if necessary | From | Robin Murphy <> |
| |
On 15/03/2024 2:53 am, Michael Kelley wrote: [...] >> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c >> index 86fe172b5958..8ce11abc691f 100644 >> --- a/kernel/dma/swiotlb.c >> +++ b/kernel/dma/swiotlb.c >> @@ -69,11 +69,13 @@ >> * @alloc_size: Size of the allocated buffer. >> * @list: The free list describing the number of free entries available >> * from each index. >> + * @padding: Number of preceding padding slots. >> */ >> struct io_tlb_slot { >> phys_addr_t orig_addr; >> size_t alloc_size; >> unsigned int list; >> + unsigned int padding; > > Even without the padding field, I presume that in > 64-bit builds this struct is already 24 bytes in size so as > to maintain 64-bit alignment for the orig_addr and > alloc_size fields. If that's the case, then adding the > padding field doesn't change the amount of memory > required for the slot array. Is that correct? Both the > "list" and "padding" fields contain only small integers, > but presumably reducing their size from "int" to "short" > wouldn't help except in 32-bit builds.
Technically I think we could shrink the whole thing down to 16 bytes*, since just 24 bits of size should still be more than enough, with the remaining 8 bits similarly plenty for a padding slot count. Depends if we think the overall memory saving is worth the marginal extra complexity of packing values into bitfields.
Thanks, Robin.
* The relevance of SWIOTLB to 32-bit builds is primarily going to be for PAE cases where phys_addr_t is still 64-bit.
| ![\](/images/icornerr.gif) |