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
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
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
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
> 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
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, >heaps, node) {
/* if the caller didn't specify this heap id */
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, >heaps, node) {
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
