lkml.org 
[lkml]   [2024]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] swiotlb: extend buffer pre-padding to alloc_align_mask if necessary
From
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.

\
 
 \ /
  Last update: 2024-05-27 15:53    [W:0.057 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site