Re: [PATCH v6 10/15] xen: add cache coloring allocator for domains

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.02.2024 15:10, Carlo Nonato wrote:
> On Mon, Feb 5, 2024 at 1:38 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 05.02.2024 12:59, Carlo Nonato wrote:
>>> On Thu, Feb 1, 2024 at 4:53 PM Jan Beulich <jbeulich@xxxxxxxx> 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