From: "Moger, Babu" <bmoger@amd.com>
To: "Luck, Tony" <tony.luck@intel.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
Babu Moger <babu.moger@amd.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"peternewman@google.com" <peternewman@google.com>,
"Yu, Fenghua" <fenghua.yu@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"thuth@redhat.com" <thuth@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"xiongwei.song@windriver.com" <xiongwei.song@windriver.com>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>,
"daniel.sneddon@linux.intel.com" <daniel.sneddon@linux.intel.com>,
"jpoimboe@kernel.org" <jpoimboe@kernel.org>,
"perry.yuan@amd.com" <perry.yuan@amd.com>,
"Huang, Kai" <kai.huang@intel.com>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"Li, Xin3" <xin3.li@intel.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"ebiggers@google.com" <ebiggers@google.com>,
"mario.limonciello@amd.com" <mario.limonciello@amd.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"tan.shaopeng@fujitsu.com" <tan.shaopeng@fujitsu.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Wieczor-Retman, Maciej" <maciej.wieczor-retman@intel.com>,
"Eranian, Stephane" <eranian@google.com>
Subject: Re: RE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Date: Thu, 19 Dec 2024 16:33:59 -0600 [thread overview]
Message-ID: <daa28f1c-1064-4adc-a99c-fdad1bc08a9f@amd.com> (raw)
In-Reply-To: <SJ1PR11MB6083B85BDBD3B756574A0E32FC062@SJ1PR11MB6083.namprd11.prod.outlook.com>
Hi Tony,
On 12/19/2024 3:45 PM, Luck, Tony wrote:
>>>>>>>> It is right thing to continue assignment if one of the domain is out of
>>>>>>>> counters. In that case how about we save the error(say error_domain) and
>>>>>>>> continue. And finally return success if both ret and error_domain are zeros.
>>>>>>>>
>>>>>>>> return ret ? ret : error_domain:
>>>>>>>
>>>>>>> If there are many domains, then you might have 3 succeed and 5 fail.
>>>>>>>
>>>>>>> I think the best you can do is return success if everything succeeded
>>>>>>> and an error if any failed.
>>>>>>
>>>>>> Yes. The above check should take care of this case.
>>>>>>
>>>>>
>>>>> If I understand correctly "error_domain" can capture the ID of
>>>>> a single failing domain. If there are multiple failing domains like
>>>>> in Tony's example then "error_domain" will not be accurate and thus
>>>>> can never be trusted. Instead of a single check of a failure user
>>>>> space is then forced to parse the more complex "mbm_assign_control"
>>>>> file to learn what succeeded and failed.
>>>>>
>>>>> Would it not be simpler to process sequentially and then fail on
>>>>> first error encountered with detailed error message? With that
>>>>> user space can determine exactly which portion of request
>>>>> succeeded and which portion failed.
>>>>
>>>> One more option is to print the error for each failure and continue. And finally return error.
>
> There's limited space allocated for use by last_cmd_*() messages:
>
> static char last_cmd_status_buf[512];
>
> seq_buf_init(&last_cmd_status, last_cmd_status_buf,
> sizeof(last_cmd_status_buf));
>
> If you keep parsing and trying to apply changes from user input you will
> quickly hit that limit.
oh. ok. Good to know.
>
>
>>>>
>>>> "Group mon1, domain:1 Out of MBM counters"
>>>>
>>>> We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
>>>
>>> This may be possible. Please keep in mind that any errors have to be
>>> easily consumed in an automated way to support the user space tools
>>> that interact with resctrl. I do not think we have thus far focused
>>> on the "last_cmd_status" buffer as part of the user space ABI so this opens
>>> up more considerations.
>>>
>>> At this time the error handling of "all domains" does not seem to be
>>> consistent and obvious to user space. From what I can tell the
>>> implementation continues on to the next domain if one domain is out
>>> of counters but it exits immediately if a counter cannot be configured
>>> on a particular domain.
>>
>> Yes. We can handle both the errors in the same way.
>
> I think it is simplest to make the "same way" be "fail on first error".
Ok. Sure. Will do thanks.
-Babu
next prev parent reply other threads:[~2024-12-19 22:34 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 20:15 [PATCH v10 00/24] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-12-12 20:15 ` [PATCH v10 01/24] x86/resctrl: Add __init attribute to functions called from resctrl_late_init() Babu Moger
2024-12-12 20:15 ` [PATCH v10 02/24] x86/cpufeatures: Add support for Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-12-12 20:15 ` [PATCH v10 03/24] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-12-12 20:15 ` [PATCH v10 04/24] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2024-12-12 20:15 ` [PATCH v10 05/24] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-12-12 20:15 ` [PATCH v10 06/24] x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags Babu Moger
2024-12-12 20:15 ` [PATCH v10 07/24] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2024-12-19 21:48 ` Reinette Chatre
2024-12-20 15:14 ` Moger, Babu
2024-12-20 17:16 ` Reinette Chatre
2024-12-12 20:15 ` [PATCH v10 08/24] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2024-12-19 21:59 ` Reinette Chatre
2024-12-20 15:31 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 09/24] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2024-12-19 22:03 ` Reinette Chatre
2024-12-20 15:41 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 10/24] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg in struct rdt_hw_mon_domain Babu Moger
2024-12-12 20:15 ` [PATCH v10 11/24] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2024-12-19 22:12 ` Reinette Chatre
2024-12-20 16:09 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 12/24] x86/resctrl: Introduce cntr_cfg to track assignable counters at domain Babu Moger
2024-12-19 22:33 ` Reinette Chatre
2024-12-20 17:33 ` Moger, Babu
2024-12-20 20:58 ` Reinette Chatre
2024-12-12 20:15 ` [PATCH v10 13/24] x86/resctrl: Introduce interface to display number of free counters Babu Moger
2024-12-19 22:50 ` Reinette Chatre
2024-12-20 18:05 ` Moger, Babu
2024-12-20 18:32 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 14/24] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2024-12-12 20:15 ` [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC Babu Moger
2024-12-19 23:04 ` Reinette Chatre
2024-12-20 19:22 ` Moger, Babu
2024-12-20 21:41 ` Reinette Chatre
2024-12-20 22:28 ` Moger, Babu
2024-12-20 23:47 ` Reinette Chatre
2024-12-21 13:40 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter Babu Moger
2024-12-12 23:37 ` Luck, Tony
2024-12-13 15:57 ` Moger, Babu
2024-12-13 16:24 ` Luck, Tony
2024-12-13 16:54 ` Moger, Babu
2024-12-18 22:01 ` Reinette Chatre
2024-12-19 19:45 ` Moger, Babu
2024-12-19 21:12 ` Reinette Chatre
2024-12-19 21:38 ` Moger, Babu
2024-12-19 21:45 ` Luck, Tony
2024-12-19 22:33 ` Moger, Babu [this message]
2024-12-19 23:22 ` Reinette Chatre
2024-12-20 20:34 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 17/24] x86/resctrl: Add the interface to unassign a counter Babu Moger
2024-12-19 23:32 ` Reinette Chatre
2024-12-20 21:38 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 18/24] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled Babu Moger
2024-12-19 23:39 ` Reinette Chatre
2024-12-21 13:45 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 19/24] x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign mode Babu Moger
2024-12-19 23:59 ` Reinette Chatre
2024-12-21 14:04 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 20/24] x86/resctrl: Introduce the interface to switch between monitor modes Babu Moger
2024-12-20 2:56 ` Reinette Chatre
2024-12-21 14:20 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 21/24] x86/resctrl: Configure mbm_cntr_assign mode if supported Babu Moger
2024-12-20 3:03 ` Reinette Chatre
2024-12-21 14:33 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 22/24] x86/resctrl: Update assignments on event configuration changes Babu Moger
2024-12-20 3:12 ` Reinette Chatre
2024-12-21 14:59 ` Moger, Babu
2024-12-23 16:20 ` Reinette Chatre
2025-01-13 20:03 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 23/24] x86/resctrl: Introduce interface to list assignment states of all the groups Babu Moger
2024-12-12 22:57 ` Luck, Tony
2024-12-13 15:23 ` Moger, Babu
2024-12-12 20:15 ` [PATCH v10 24/24] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-12-20 3:23 ` Reinette Chatre
2024-12-21 15:28 ` Moger, Babu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daa28f1c-1064-4adc-a99c-fdad1bc08a9f@amd.com \
--to=bmoger@amd.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@google.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=perry.yuan@amd.com \
--cc=peternewman@google.com \
--cc=reinette.chatre@intel.com \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=xin3.li@intel.com \
--cc=xiongwei.song@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®