From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>
Cc: "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.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>,
"quic_neeraju@quicinc.com" <quic_neeraju@quicinc.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"damien.lemoal@opensource.wdc.com"
<damien.lemoal@opensource.wdc.com>,
"songmuchun@bytedance.com" <songmuchun@bytedance.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jpoimboe@kernel.org" <jpoimboe@kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"chang.seok.bae@intel.com" <chang.seok.bae@intel.com>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>,
"jmattson@google.com" <jmattson@google.com>,
"daniel.sneddon@linux.intel.com" <daniel.sneddon@linux.intel.com>,
"Das1, Sandipan" <Sandipan.Das@amd.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"bagasdotme@gmail.com" <bagasdotme@gmail.com>,
"eranian@google.com" <eranian@google.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"jarkko@kernel.org" <jarkko@kernel.org>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"quic_jiles@quicinc.com" <quic_jiles@quicinc.com>,
"peternewman@google.com" <peternewman@google.com>
Subject: Re: [PATCH v3 1/7] x86/resctrl: Add multiple tasks to the resctrl group at once
Date: Mon, 20 Mar 2023 13:29:56 -0500 [thread overview]
Message-ID: <3d8585fe-ab2f-6a06-bfc0-47569d755c69@amd.com> (raw)
In-Reply-To: <ec71ca8a-2550-8e01-7830-6e9f62ee4e95@intel.com>
Hi Reinette,
On 3/20/23 11:52, Reinette Chatre wrote:
> Hi Babu,
>
> On 3/20/2023 8:07 AM, Moger, Babu wrote:
>> On 3/16/23 15:33, Reinette Chatre wrote:
>>> On 3/16/2023 12:51 PM, Moger, Babu wrote:
>>>> On 3/16/23 12:12, Reinette Chatre wrote:
>>>>> On 3/16/2023 9:27 AM, Moger, Babu wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Reinette Chatre <reinette.chatre@intel.com>
>>>>>>> Sent: Wednesday, March 15, 2023 1:33 PM
>>>>>>> To: Moger, Babu <Babu.Moger@amd.com>; corbet@lwn.net;
>>>>>>> tglx@linutronix.de; mingo@redhat.com; bp@alien8.de
>>>>>>> Cc: fenghua.yu@intel.com; dave.hansen@linux.intel.com; x86@kernel.org;
>>>>>>> hpa@zytor.com; paulmck@kernel.org; akpm@linux-foundation.org;
>>>>>>> quic_neeraju@quicinc.com; rdunlap@infradead.org;
>>>>>>> damien.lemoal@opensource.wdc.com; songmuchun@bytedance.com;
>>>>>>> peterz@infradead.org; jpoimboe@kernel.org; pbonzini@redhat.com;
>>>>>>> chang.seok.bae@intel.com; pawan.kumar.gupta@linux.intel.com;
>>>>>>> jmattson@google.com; daniel.sneddon@linux.intel.com; Das1, Sandipan
>>>>>>> <Sandipan.Das@amd.com>; tony.luck@intel.com; james.morse@arm.com;
>>>>>>> linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> bagasdotme@gmail.com; eranian@google.com; christophe.leroy@csgroup.eu;
>>>>>>> jarkko@kernel.org; adrian.hunter@intel.com; quic_jiles@quicinc.com;
>>>>>>> peternewman@google.com
>>>>>>> Subject: Re: [PATCH v3 1/7] x86/resctrl: Add multiple tasks to the resctrl group
>>>>>>> at once
>>>>>>>
>>>>>>> Hi Babu,
>>>>>>>
>>>>>>> On 3/2/2023 12:24 PM, Babu Moger wrote:
>>>>>>>> The resctrl task assignment for MONITOR or CONTROL group needs to be
>>>>>>>> done one at a time. For example:
>>>>>>>>
>>>>>>>> $mount -t resctrl resctrl /sys/fs/resctrl/
>>>>>>>> $mkdir /sys/fs/resctrl/clos1
>>>>>>>> $echo 123 > /sys/fs/resctrl/clos1/tasks
>>>>>>>> $echo 456 > /sys/fs/resctrl/clos1/tasks
>>>>>>>> $echo 789 > /sys/fs/resctrl/clos1/tasks
>>>>>>>>
>>>>>>>> This is not user-friendly when dealing with hundreds of tasks. Also,
>>>>>>>> there is a syscall overhead for each command executed from user space.
>>>>>>>
>>>>>>> To support this change it may also be helpful to add that moving tasks take the
>>>>>>> mutex so attempting to move tasks in parallel will not achieve a significant
>>>>>>> performance gain.
>>>>>>
>>>>>> Agree. It may not be significant performance gain. Will remove this line.
>>>>>
>>>>> It does not sound as though you are actually responding to my comment.
>>>>
>>>> I am confused. I am already saying there is syscall overhead for each
>>>> command if we move the tasks one by one. Now do you want me to add "moving
>>>> tasks take the mutex so attempting to move tasks in parallel will not
>>>> achieve a significant performance gain".
>>>>
>>>> It is contradictory, So, I wanted to remove the line about performance.
>>>> Did I still miss something?
>>>
>>> Where is the contradiction?
>>>
>>> Consider your example:
>>> $echo 123 > /sys/fs/resctrl/clos1/tasks
>>> $echo 456 > /sys/fs/resctrl/clos1/tasks
>>> $echo 789 > /sys/fs/resctrl/clos1/tasks
>>>
>>> Yes, there is syscall overhead for each of the above lines. My statement was in
>>> support of this work by stating that a user aiming to improve performance by
>>> attempting the above in parallel would not be able to see achieve significant
>>> performance gain since the calls would end up being serialized.
>>
>> ok. Sure. Will add the text. I may modify little bit.
>>>
>>> You are providing two motivations (a) "user-friendly when dealing with
>>> hundreds of tasks", and (b) syscall overhead. Have you measured the
>>> improvement this solution provides?
>>
>> No. I have not measured the performance improvement.
>
> The changelog makes a claim that the current implementation has overhead
> that is removed with this change. There is no data to support this claim.
My main motivation for this change is to make it user-friendly. So that
users can search the pid's and assign multiple tasks at a time. Originally
I did not have the line for performance. Actually, I don't want to claim
performance benefits. I will remove the performance claims.
>
> ...
>
>>>>>>>> +
>>>>>>>> + buf[nbytes - 1] = '\0';
>>>>>>>> +
>>>>>>>> rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>>>>>>> if (!rdtgrp) {
>>>>>>>> rdtgroup_kn_unlock(of->kn);
>>>>>>>> return -ENOENT;
>>>>>>>> }
>>>>>>>> +
>>>>>>>> +next:
>>>>>>>> + if (!buf || buf[0] == '\0')
>>>>>>>> + goto unlock;
>>>>>>>> +
>>>>>>>> + pid_str = strim(strsep(&buf, ","));
>>>>>>>> +
>>>>>>>
>>>>>>> Could lib/cmdline.c:get_option() be useful?
>>>>>>
>>>>>> Yes. We could that also. May not be required for the simple case like this.
>>>>>
>>>>> Please keep an eye out for how much of it you end up duplicating ....
>>>>
>>>> Using the get_options will require at least two calls(one to get the
>>>> length and then read the integers). Also need to allocate the integers
>>>> array dynamically. That is lot code if we are going that route.
>>>>
>>>
>>> I did not ask about get_options(), I asked about get_option().
>>
>> If you insist, will use get_option. But we still have to loop thru all the
>> string till get_option returns 0. I can try that.
>
>
> I just asked whether get_option() could be useful. Could you please point out what
> I said that made you think that I insist on this change being made? If it matches
> your usage, then know it is available, if it does not, then don't use it.
Ok. I dont see a major benefit using get_option here. So, not planning to
to use it.
>
> ...
>
>>>> I can say "The failure pid will be logged in
>>>> /sys/fs/resctrl/info/last_cmd_status file."
>>>
>>> That will not be accurate. Not all errors include the pid.
>>
>> Can you please suggest?
>
> last_cmd_status provides a 512 char buffer to communicate details
> to the user. The buffer is cleared before the loop that moves all the
> tasks start. If an error is encountered, a detailed message is written
> to the buffer. One option may be to append a string to the buffer that
> includes the pid? Perhaps something like:
> rdt_last_cmd_printf("Error encountered while moving task %d\n", pid);
ok. Will try to add and test it.
>
> Please feel free to improve.
>
> Reinette
>
>
--
Thanks
Babu Moger
next prev parent reply other threads:[~2023-03-20 18:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 20:24 [PATCH v3 0/7] x86/resctrl: Miscellaneous resctrl features Babu Moger
2023-03-02 20:24 ` [PATCH v3 1/7] x86/resctrl: Add multiple tasks to the resctrl group at once Babu Moger
2023-03-15 18:32 ` Reinette Chatre
2023-03-16 16:27 ` Moger, Babu
2023-03-16 17:12 ` Reinette Chatre
2023-03-16 19:51 ` Moger, Babu
2023-03-16 20:33 ` Reinette Chatre
2023-03-20 15:07 ` Moger, Babu
2023-03-20 15:15 ` Moger, Babu
2023-03-20 16:52 ` Reinette Chatre
2023-03-20 18:29 ` Moger, Babu [this message]
2023-03-02 20:24 ` [PATCH v3 2/7] x86/resctrl: Remove few unnecessary rftype flags Babu Moger
2023-03-15 18:33 ` Reinette Chatre
2023-03-16 20:31 ` Moger, Babu
2023-03-16 20:41 ` Reinette Chatre
2023-03-16 21:11 ` Moger, Babu
2023-03-16 21:17 ` Reinette Chatre
2023-03-20 13:35 ` Moger, Babu
2023-03-02 20:24 ` [PATCH v3 3/7] x86/resctrl: Rename rftype flags for consistency Babu Moger
2023-03-02 20:24 ` [PATCH v3 4/7] x86/resctrl: Re-arrange RFTYPE flags based on hierarchy Babu Moger
2023-03-15 18:37 ` Reinette Chatre
2023-03-21 15:54 ` Moger, Babu
2023-03-22 18:46 ` Reinette Chatre
2023-03-02 20:24 ` [PATCH v3 5/7] x86/resctrl: Display the RMID and COSID for resctrl groups Babu Moger
2023-03-15 18:42 ` Reinette Chatre
2023-03-20 16:52 ` Moger, Babu
2023-03-20 17:00 ` Reinette Chatre
2023-03-20 17:10 ` James Morse
2023-03-20 19:53 ` Moger, Babu
2023-03-20 20:59 ` Stephane Eranian
2023-03-22 13:49 ` Moger, Babu
2023-03-02 20:25 ` [PATCH v3 6/7] x86/resctrl: Introduce -o debug mount option Babu Moger
2023-03-15 18:43 ` Reinette Chatre
2023-03-22 14:01 ` Moger, Babu
2023-03-02 20:25 ` [PATCH v3 7/7] x86/resctrl: Add debug files when mounted with debug option Babu Moger
2023-03-15 18:45 ` Reinette Chatre
2023-03-22 15:09 ` 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=3d8585fe-ab2f-6a06-bfc0-47569d755c69@amd.com \
--to=babu.moger@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bagasdotme@gmail.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=christophe.leroy@csgroup.eu \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=quic_jiles@quicinc.com \
--cc=quic_neeraju@quicinc.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=songmuchun@bytedance.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).