All of lore.kernel.org
 help / color / mirror / Atom feed
* staging: ion: ION allocation fall back order depends on heap linkage order
@ 2018-01-28 16:24 Alexey Skidanov
  2018-02-06 23:48 ` Laura Abbott
  0 siblings, 1 reply; 7+ messages in thread
From: Alexey Skidanov @ 2018-01-28 16:24 UTC (permalink / raw)
  To: devel; +Cc: linux-kernel

Hi,

According to my understanding, the allocation fall back order
completely depends on heap->id that is assigned during the heap
creation:
   plist_for_each_entry(heap, &dev->heaps, node) {
        /* if the caller didn't specify this heap id */
        if (!((1 << heap->id) & heap_id_mask))
            continue;
        buffer = ion_buffer_create(heap, dev, len, flags);
        if (!IS_ERR(buffer))
            break;
    }

On creation, each heap is added to the priority list according to the
priority assigned:

...
static int heap_id;
...
void ion_device_add_heap(struct ion_heap *heap)
{
        ...
        heap->id = heap_id++;
        ...
}


The order of creation is the order of linkage defined in the Makefile.
Thus, by default, we have:

heap id 2, type ION_HEAP_TYPE_DMA
heap id 1, type ION_HEAP_TYPE_SYSTEM
heap id 0, type ION_HEAP_TYPE_SYSTEM_CONTIG

Changing the linkage order:
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index bb30bf8..e05052c 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
-obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
 obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
 obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o

I get the following order:

heap id 2, type ION_HEAP_TYPE_SYSTEM
heap id 1, type ION_HEAP_TYPE_SYSTEM_CONTIG
heap id 0, type ION_HEAP_TYPE_DMA

So, if the user specifies more than 1 heap in the heap_id_mask during
allocation, the allocation fall back order completely depends on the
order of linkage. Probably, it's better to let the user to define the
fall back order (and NOT to be dependent on the linkage order at all)
?

Thanks,
Alexey
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
  2018-01-28 16:24 staging: ion: ION allocation fall back order depends on heap linkage order Alexey Skidanov
@ 2018-02-06 23:48 ` Laura Abbott
       [not found]   ` <CAM7Y4U_hw5anfgGyAK2uVxOxA3zPoJtOa93mrw8k7xfyOaSTUA@mail.gmail.com>
  0 siblings, 1 reply; 7+ messages in thread
From: Laura Abbott @ 2018-02-06 23:48 UTC (permalink / raw)
  To: Alexey Skidanov, devel; +Cc: linux-kernel

On 01/28/2018 08:24 AM, Alexey Skidanov wrote:
> Hi,
> 
> According to my understanding, the allocation fall back order
> completely depends on heap->id that is assigned during the heap
> creation:
>     plist_for_each_entry(heap, &dev->heaps, node) {
>          /* if the caller didn't specify this heap id */
>          if (!((1 << heap->id) & heap_id_mask))
>              continue;
>          buffer = ion_buffer_create(heap, dev, len, flags);
>          if (!IS_ERR(buffer))
>              break;
>      }
> 
> On creation, each heap is added to the priority list according to the
> priority assigned:
> 
> ...
> static int heap_id;
> ...
> void ion_device_add_heap(struct ion_heap *heap)
> {
>          ...
>          heap->id = heap_id++;
>          ...
> }
> 
> 
> The order of creation is the order of linkage defined in the Makefile.
> Thus, by default, we have:
> 
> heap id 2, type ION_HEAP_TYPE_DMA
> heap id 1, type ION_HEAP_TYPE_SYSTEM
> heap id 0, type ION_HEAP_TYPE_SYSTEM_CONTIG
> 
> Changing the linkage order:
> diff --git a/drivers/staging/android/ion/Makefile
> b/drivers/staging/android/ion/Makefile
> index bb30bf8..e05052c 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,6 @@
>   # SPDX-License-Identifier: GPL-2.0
>   obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
> -obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
>   obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
>   obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
>   obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> +obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
> 
> I get the following order:
> 
> heap id 2, type ION_HEAP_TYPE_SYSTEM
> heap id 1, type ION_HEAP_TYPE_SYSTEM_CONTIG
> heap id 0, type ION_HEAP_TYPE_DMA
> 
> So, if the user specifies more than 1 heap in the heap_id_mask during
> allocation, the allocation fall back order completely depends on the
> order of linkage. Probably, it's better to let the user to define the
> fall back order (and NOT to be dependent on the linkage order at all)
> ?
> 

Yup, you've hit upon a key problem. Having fallbacks be stable
was always a problem and the recommendation these days is to
not rely on them. You can specify a heap at a time and fallback
manually if you want that behavior.

If you have a proposal to make fallbacks work reliably without
overly complicating the ABI I'm happy to review it.

Thanks,
Laura

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
       [not found]   ` <CAM7Y4U_hw5anfgGyAK2uVxOxA3zPoJtOa93mrw8k7xfyOaSTUA@mail.gmail.com>
@ 2018-02-07  7:05     ` Alexey Skidanov
  2018-02-07 14:58       ` Laura Abbott
  0 siblings, 1 reply; 7+ messages in thread
From: Alexey Skidanov @ 2018-02-07  7:05 UTC (permalink / raw)
  To: Laura Abbott, devel; +Cc: linux-kernel



> Yup, you've hit upon a key problem. Having fallbacks be stable
> was always a problem and the recommendation these days is to
> not rely on them. You can specify a heap at a time and fallback
> manually if you want that behavior.
> 
> If you have a proposal to make fallbacks work reliably without
> overly complicating the ABI I'm happy to review it.
> 
> Thanks,
> Laura
> 
I think it's possible to "automate" the "manual fallback" behavior. But
the real issues is using heap id to specify the particular heap object.

Current API (allocation IOCTL) requires to specify the particular heap
object by using heap id. From the other hand, the user space doesn't
control the heaps creation order and heap id assignment. So it may be
tricky, especially when more than one object of the same heap type is
created automatically.

Thanks,
Alexey


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
  2018-02-07  7:05     ` Alexey Skidanov
@ 2018-02-07 14:58       ` Laura Abbott
  2018-02-07 15:10         ` Alexey Skidanov
  0 siblings, 1 reply; 7+ messages in thread
From: Laura Abbott @ 2018-02-07 14:58 UTC (permalink / raw)
  To: Alexey Skidanov, devel; +Cc: linux-kernel

On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
> 
> 
>> Yup, you've hit upon a key problem. Having fallbacks be stable
>> was always a problem and the recommendation these days is to
>> not rely on them. You can specify a heap at a time and fallback
>> manually if you want that behavior.
>>
>> If you have a proposal to make fallbacks work reliably without
>> overly complicating the ABI I'm happy to review it.
>>
>> Thanks,
>> Laura
>>
> I think it's possible to "automate" the "manual fallback" behavior. But
> the real issues is using heap id to specify the particular heap object.
> 
> Current API (allocation IOCTL) requires to specify the particular heap
> object by using heap id. From the other hand, the user space doesn't
> control the heaps creation order and heap id assignment. So it may be
> tricky, especially when more than one object of the same heap type is
> created automatically.
> 
> Thanks,
> Alexey
> 
> 

The query ioctl is designed to get the heap ID information without
needing to rely on the linking order or anything else defined in
the kernel.

Thanks,
Laura
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
  2018-02-07 14:58       ` Laura Abbott
@ 2018-02-07 15:10         ` Alexey Skidanov
  2018-02-07 15:32           ` Laura Abbott
  0 siblings, 1 reply; 7+ messages in thread
From: Alexey Skidanov @ 2018-02-07 15:10 UTC (permalink / raw)
  To: Laura Abbott, devel; +Cc: linux-kernel



On 02/07/2018 04:58 PM, Laura Abbott wrote:
> On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
>>
>>
>>> Yup, you've hit upon a key problem. Having fallbacks be stable
>>> was always a problem and the recommendation these days is to
>>> not rely on them. You can specify a heap at a time and fallback
>>> manually if you want that behavior.
>>>
>>> If you have a proposal to make fallbacks work reliably without
>>> overly complicating the ABI I'm happy to review it.
>>>
>>> Thanks,
>>> Laura
>>>
>> I think it's possible to "automate" the "manual fallback" behavior. But
>> the real issues is using heap id to specify the particular heap object.
>>
>> Current API (allocation IOCTL) requires to specify the particular heap
>> object by using heap id. From the other hand, the user space doesn't
>> control the heaps creation order and heap id assignment. So it may be
>> tricky, especially when more than one object of the same heap type is
>> created automatically.
>>
>> Thanks,
>> Alexey
>>
>>
> 
> The query ioctl is designed to get the heap ID information without
> needing to rely on the linking order or anything else defined in
> the kernel.
> 
> Thanks,
> Laura

That is true. But if we have 2 *automatically created* heaps of the same
type, how userspace can distinguish between them?

Thanks,
Alexey
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
  2018-02-07 15:10         ` Alexey Skidanov
@ 2018-02-07 15:32           ` Laura Abbott
  2018-02-07 15:49             ` Alexey Skidanov
  0 siblings, 1 reply; 7+ messages in thread
From: Laura Abbott @ 2018-02-07 15:32 UTC (permalink / raw)
  To: Alexey Skidanov, devel; +Cc: linux-kernel

On 02/07/2018 07:10 AM, Alexey Skidanov wrote:
> 
> 
> On 02/07/2018 04:58 PM, Laura Abbott wrote:
>> On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
>>>
>>>
>>>> Yup, you've hit upon a key problem. Having fallbacks be stable
>>>> was always a problem and the recommendation these days is to
>>>> not rely on them. You can specify a heap at a time and fallback
>>>> manually if you want that behavior.
>>>>
>>>> If you have a proposal to make fallbacks work reliably without
>>>> overly complicating the ABI I'm happy to review it.
>>>>
>>>> Thanks,
>>>> Laura
>>>>
>>> I think it's possible to "automate" the "manual fallback" behavior. But
>>> the real issues is using heap id to specify the particular heap object.
>>>
>>> Current API (allocation IOCTL) requires to specify the particular heap
>>> object by using heap id. From the other hand, the user space doesn't
>>> control the heaps creation order and heap id assignment. So it may be
>>> tricky, especially when more than one object of the same heap type is
>>> created automatically.
>>>
>>> Thanks,
>>> Alexey
>>>
>>>
>>
>> The query ioctl is designed to get the heap ID information without
>> needing to rely on the linking order or anything else defined in
>> the kernel.
>>
>> Thanks,
>> Laura
> 
> That is true. But if we have 2 *automatically created* heaps of the same
> type, how userspace can distinguish between them?
> 
> Thanks,
> Alexey
> 

The query ioctl also gives the name which should be different
for each heap. It's not ideal but the name/heap type are the best
way to differentiate between heaps without resorting to hard
coding.

Thanks,
Laura
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: staging: ion: ION allocation fall back order depends on heap linkage order
  2018-02-07 15:32           ` Laura Abbott
@ 2018-02-07 15:49             ` Alexey Skidanov
  0 siblings, 0 replies; 7+ messages in thread
From: Alexey Skidanov @ 2018-02-07 15:49 UTC (permalink / raw)
  To: Laura Abbott, devel; +Cc: linux-kernel



On 02/07/2018 05:32 PM, Laura Abbott wrote:
> On 02/07/2018 07:10 AM, Alexey Skidanov wrote:
>>
>>
>> On 02/07/2018 04:58 PM, Laura Abbott wrote:
>>> On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
>>>>
>>>>
>>>>> Yup, you've hit upon a key problem. Having fallbacks be stable
>>>>> was always a problem and the recommendation these days is to
>>>>> not rely on them. You can specify a heap at a time and fallback
>>>>> manually if you want that behavior.
>>>>>
>>>>> If you have a proposal to make fallbacks work reliably without
>>>>> overly complicating the ABI I'm happy to review it.
>>>>>
>>>>> Thanks,
>>>>> Laura
>>>>>
>>>> I think it's possible to "automate" the "manual fallback" behavior. But
>>>> the real issues is using heap id to specify the particular heap object.
>>>>
>>>> Current API (allocation IOCTL) requires to specify the particular heap
>>>> object by using heap id. From the other hand, the user space doesn't
>>>> control the heaps creation order and heap id assignment. So it may be
>>>> tricky, especially when more than one object of the same heap type is
>>>> created automatically.
>>>>
>>>> Thanks,
>>>> Alexey
>>>>
>>>>
>>>
>>> The query ioctl is designed to get the heap ID information without
>>> needing to rely on the linking order or anything else defined in
>>> the kernel.
>>>
>>> Thanks,
>>> Laura
>>
>> That is true. But if we have 2 *automatically created* heaps of the same
>> type, how userspace can distinguish between them?
>>
>> Thanks,
>> Alexey
>>
> 
> The query ioctl also gives the name which should be different
> for each heap. It's not ideal but the name/heap type are the best
> way to differentiate between heaps without resorting to hard
> coding.
> 
> Thanks,
> Laura

You are correct ... It will work (assuming that user space developer
knows where to look for the name :) )

So, the userspace may pass the list of pairs [heap type, name] (as part
of allocation ioctl) defining the fallback order.

Thanks,
Alexey

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-02-07 15:49 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-28 16:24 staging: ion: ION allocation fall back order depends on heap linkage order Alexey Skidanov
2018-02-06 23:48 ` Laura Abbott
     [not found]   ` <CAM7Y4U_hw5anfgGyAK2uVxOxA3zPoJtOa93mrw8k7xfyOaSTUA@mail.gmail.com>
2018-02-07  7:05     ` Alexey Skidanov
2018-02-07 14:58       ` Laura Abbott
2018-02-07 15:10         ` Alexey Skidanov
2018-02-07 15:32           ` Laura Abbott
2018-02-07 15:49             ` Alexey Skidanov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.