Re: [PATCH 1/1] swiotlb: extend buffer pre-padding to alloc_align_mask if necessary

[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.