Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] staging: android: ion: Add requested allocation alignment
To:     Laura Abbott <labbott@redhat.com>, sumit.semwal@linaro.org,
        gregkh@linuxfoundation.org, arve@android.com, tkjos@android.com,
        maco@android.com, devel@driverdev.osuosl.org
Cc:     linux-kernel@vger.kernel.org, Liam Mark <lmark@codeaurora.org>
References: <1518257863-6903-1-git-send-email-alexey.skidanov@intel.com>
 <ae413008-6c8b-5e53-9251-d11f4ae9713a@redhat.com>
 <8284b2ba-a532-23fd-4c52-7ac556d63918@intel.com>
 <ed842c91-4c4c-7dc0-3957-7e2684e24e32@redhat.com>
 <8eb1f6c9-e08d-c6a5-934a-c7e7873d79f2@intel.com>
 <de9c0071-c45b-608c-67ab-015b284a6082@redhat.com>
From:   Alexey Skidanov <alexey.skidanov@intel.com>
Message-ID: <f1b008cc-b94d-2ab1-b618-7b6b13f9298a@intel.com>
Date:   Mon, 12 Feb 2018 23:39:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <de9c0071-c45b-608c-67ab-015b284a6082@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 02/12/2018 10:46 PM, Laura Abbott wrote:
> 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.
Yes you are correct. I just realized that it isn't even backward
compatible.
> 
>> 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
It seems, that there is no way to do it without some ABI change?

Thanks,
Alexey