[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <938f4939-39ff-26f2-63d8-79bb67d0d45a@amd.com>
Date: Thu, 17 Aug 2023 14:21:55 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de
Cc: fenghua.yu@...el.com, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, paulmck@...nel.org, akpm@...ux-foundation.org,
quic_neeraju@...cinc.com, rdunlap@...radead.org,
damien.lemoal@...nsource.wdc.com, songmuchun@...edance.com,
peterz@...radead.org, jpoimboe@...nel.org, pbonzini@...hat.com,
chang.seok.bae@...el.com, pawan.kumar.gupta@...ux.intel.com,
jmattson@...gle.com, daniel.sneddon@...ux.intel.com,
sandipan.das@....com, tony.luck@...el.com, james.morse@....com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
bagasdotme@...il.com, eranian@...gle.com,
christophe.leroy@...roup.eu, jarkko@...nel.org,
adrian.hunter@...el.com, quic_jiles@...cinc.com,
peternewman@...gle.com
Subject: Re: [PATCH v7 4/8] x86/resctrl: Add comments on RFTYPE flags
hierarchy
Hi Reinette,
On 8/17/23 12:42, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/17/2023 10:07 AM, Moger, Babu wrote:
>> On 8/17/23 10:37, Reinette Chatre wrote:
>>> On 8/17/2023 7:20 AM, Moger, Babu wrote:
>
>>>> + *
>>>> + * --> RFTYPE_MON (Files for all monitoring resources)
>>>> + * directory: L3_MON
>>>
>>> Should this not be below RFTYPE_RES_CACHE?
>>
>> This is kind of odd. I know why you are saying it. Wouldn't it confuse the
>> user? Then, it feels like mon_features and num_rmids don't belong L3_MON.
>>
>
> This is exactly the confusion that I attempted to highlight in my
> first response to this patch. The same issue is present for
> "num_closids" (which is currently treated differently ... at least
> these need to be consistent). How can it be made obvious that
> these files are present in all resource sub-directories while
> also capturing the hierarchy of the RFTYPE flags? I could not
> find a clear way and that is why I ended up removing the directories
> in my earlier proposal and just stick to documenting the file flags
> that only applies to files anyway.
>
> What do you think of something like below? It has duplication
> but may be less confusing while still capturing the flags
> accurately?
Yes. This looks good to me.
>
> --> RFTYPE_MON (Files for all monitoring resources)
> Directory: L3_MON
> Files: mon_features, num_rmids
>
> --> RFTYPE_RES_CACHE (Files for cache monitoring resources)
> Directory: L3_MON
> Files: max_threshold_occupancy, mbm_total_bytes_config,
> mbm_local_bytes_config
>
> --> RFTYPE_CTRL (Files for all control resources)
> Directories: L2, L3, MB, SMBA
> File: num_closids
>
> --> RFTYPE_CTRL (Files for all control resources)
> Directories: L2, L3
> Files: bit_usage, cbm_mask, min_cbm_bits,
> shareable_bits
>
> --> RFTYPE_RES_MB (Files for memory control resources)
> Directories: MB, SMBA
> Files: bandwidth_gran, delay_linear,
> min_bandwidth, thread_throttle_mode
>
>
>>>> + * Files: bit_usage, cbm_mask, min_cbm_bits,
>>>> + * shareable_bits
>>>
>>> The extra indent is not clear to me. Did you do it to represent
>>> a hierarchy or just to line up the ":"?
>>
>> This is to line up with :. I can fix it.
>>
>> Just wondering how do you notice these tabs? My linux diff does not show
>> any difference. Are you using any utilities to see these tabs?
>
> My editor is configured to visualize tabs and trailing spaces. In
> this case it was just how my email client displayed it though.
>
ok.
Thanks
Babu Moger
Powered by blists - more mailing lists