[PATCH] staging: android: ion: Add requested allocation alignment

[Laura Abbott]

On 02/12/2018 12:22 PM, Alexey Skidanov wrote:
> 
> 
> On 02/12/2018 09:52 PM, Laura Abbott wrote:
>> On 02/12/2018 11:11 AM, Alexey Skidanov wrote:
>>>
>>> On 02/12/2018 08:42 PM, Laura Abbott wrote:
>>>> On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
>>>>> Current ion defined allocation ioctl doesn't allow to specify the
>>>>> requested
>>>>> allocation alignment. CMA heap allocates buffers aligned on buffer size
>>>>> page order.
>>>>>
>>>>> Sometimes, the alignment requirement is less restrictive. In such
>>>>> cases,
>>>>> providing specific alignment may reduce the external memory
>>>>> fragmentation
>>>>> and in some cases it may avoid the allocation request failure.
>>>>>
>>>> I really do not want to bring this back as part of the regular
>>>> ABI.
>>> Yes, I know it was removed in 4.12.
>>> Having an alignment parameter that gets used for exactly
>>>> one heap only leads to confusion (which is why it was removed
>>>> from the ABI in the first place).
>>> You are correct regarding the CMA heap. But, probably it may be used by
>>> custom heap as well.
>>
>> I can think of a lot of instances where it could be used but
>> ultimately there needs to be an actual in kernel user who wants
>> it.
>>
>>>> The alignment came from the behavior of the DMA APIs. Do you
>>>> actually need to specify any alignment from userspace or do
>>>> you only need page size?
>>> Yes. If CMA gives it for free, I would suggest to let the ion user to
>>> decide
>>
>> I'm really not convinced changing the ABI yet again just to let
>> the user decide is actually worth it. If we can manage it, I'd
>> much rather see a proposal that doesn't change the ABI.
> I didn't actually change the ABI - I just use the "unused" member:
> struct ion_allocation_data {
> @@ -80,7 +79,7 @@ struct ion_allocation_data {
>          __u32 heap_id_mask;
>          __u32 flags;
>          __u32 fd;
> -       __u32 unused;
> +       __u32 align;
>   };
> 

Something that was previously unused is now being used. That's a change
in how the structure is interpreted which is an ABI change, especially
since we haven't been checking that the __unused field is set
to 0.

> As an alternative, I may add __u64 heap_specific_param - but this will
> change the ABI. But, probably it makes the ABI more generic?

Why does the ABI need to be more generic? If we change the ABI
we're stuck with it and I'd like to approach it as the very last
resort.

Thanks,
Laura