On 05.02.2024 15:10, Carlo Nonato wrote:
> On Mon, Feb 5, 2024 at 1:38 PM Jan Beulich <jbeul...@suse.com> wrote:
>> On 05.02.2024 12:59, Carlo Nonato wrote:
>>> On Thu, Feb 1, 2024 at 4:53 PM Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 29.01.2024 18:18, Carlo Nonato wrote:
>>>>> @@ -2458,7 +2626,14 @@ struct page_info *alloc_domheap_pages(
>>>>> if ( memflags & MEMF_no_owner )
>>>>> memflags |= MEMF_no_refcount;
>>>>>
>>>>> - if ( !dma_bitsize )
>>>>> + /* Only domains are supported for coloring */
>>>>> + if ( d && llc_coloring_enabled )
>>>>> + {
>>>>> + /* Colored allocation must be done on 0 order */
>>>>> + if ( order || (pg = alloc_color_heap_page(memflags, d)) == NULL )
>>>>> + return NULL;
>>>>> + }
>>>>
>>>> I think I had asked before: What about MEMF_node() or MEMF_bits()
>>>> having been used by the caller?
>>>
>>> MEMF_node() is used for NUMA, right? I think that for the moment, since
>>> cache
>>> coloring is supported only on arm64 and NUMA is not yet supported, it's safe
>>> to ignore it.
>>
>> NUMA or not, I'm wary of silent ignoring of inputs. I'd rather request
>> that, just like with staticmem, precautions are then taken to avoid
>> coloring and NUMA to be used together. Recall that much like your work,
>> work to support NUMA is also in progress (unless it was canceled, but
>> not so announced).
>
> Ok.
>
>>> I'm not sure I understood what MEMF_bits() is for. It restricts the
>>> allocator
>>> to return pages in some range, right?
>>
>> Correct.
>
> So I need to think about this, since I see no easy way of supporting such a
> thing with the current colored allocator implementation.
> Do you have any suggestions?
Well, at least properly fail requests you can't fulfill.
Jan
