lkml.org 
[lkml]   [2023]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v3 06/19] x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID
    From
    Hi James,

    On 3/20/2023 10:26 AM, James Morse wrote:

    ...

    > +/**
    > + * resctrl_closid_is_dirty - Determine if all RMID associated with this CLOSID
    > + * are available.
    > + * @closid: The CLOSID that is being queried.
    > + *
    > + * MPAM's equivalent of RMID are per-CLOSID, meaning a freshly allocated CLOSID
    > + * may not be able to allocate clean RMID. To avoid this the allocator will
    > + * only return clean CLOSID. This is enough for now as it allows MPAM systems
    > + * to use resctrl. This suffers from the problem that there may be no CLOSID
    > + * where all the RMID are clean, causing the CLOSID allocation to fail.
    > + * This can be improved (once MPAM support is upstream) to return the cleanest
    > + * CLOSID where PMG=0 is clean. This would allow the CLOSID allocation to

    Why does PMG=0 have to be the clean ID?

    I am wondering about the use cases here. When a new CLOSID needs to be allocated,
    would it not be useful to instead have a utility that returns the "cleanest" CLOSID?
    Instead of picking an available CLOSID and then always have to check if it is
    "dirty or not", why not have a utility that picks the CLOSID with the most
    available PMGs?

    Reinette

    \
     
     \ /
      Last update: 2023-04-01 01:22    [W:2.322 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site