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; }; As an alternative, I may add __u64 heap_specific_param - but this will change the ABI. But, probably it makes the ABI more generic? > >>> Thanks, >>> Laura >>> >> Thanks, >> Alexey >> > Thanks, Alexey _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel