Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6ae80709-cf44-43bd-d539-650f72dcd670@intel.com>
Date:   Fri, 5 May 2023 11:49:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.10.1
Subject: Re: [PATCH v4 1/7] x86/resctrl: Add multiple tasks to the resctrl
 group at once
Content-Language: en-US
To:     "Moger, Babu" <Babu.Moger@amd.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>
References: <168177435378.1758847.8317743523931859131.stgit@bmoger-ubuntu>
 <168177444676.1758847.11474266921067437724.stgit@bmoger-ubuntu>
 <51a1b46e-9162-83bc-29df-8a154059f847@intel.com>
 <MW3PR12MB4553BAD1A9390D518D9919A895729@MW3PR12MB4553.namprd12.prod.outlook.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <MW3PR12MB4553BAD1A9390D518D9919A895729@MW3PR12MB4553.namprd12.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L3JLckt6QW84cFMwRDdDMy85aWN4QThJRkx1STRmeUxEU1J1Z1hRMVRjYVg0?=
 =?utf-8?B?aFpHa0lQYW1ZR2ttSElBaUxrQWVoSENpcGFHbVlEKzV5Y3RXNWVwK3F0L3J2?=
 =?utf-8?B?UzZLeXlUNXBJK0ZFaWw1TTdac1RkTVJ4U1NkR3EyK2J5N3RKNmJXMUJkVldm?=
 =?utf-8?B?c2lxUGRKOWtjMUgvYU5KOHF4eXV0ZkMrUEFzbmxJYUIvb0xNSlp0M1RiOEF6?=
 =?utf-8?B?dThoUHdrT2w1QmNIdUR6Ukg5blp5N0lVN2ZRcWQyTW9wQjlzbFVROUxhS2R1?=
 =?utf-8?B?Zll5QmtBWkNhVm5ZUE9uVW8rL29EWHVlb2d0RmZBUjlBVlkwU1Uwck9OeFlW?=
 =?utf-8?B?WXFrVkR4SW1IS0VQcXhZS3BaZHhOZlBocVNCbTJaNGV6NEJhMDhRaWNzaDZ4?=
 =?utf-8?B?cFV0RXpxSDdUZ3dJdnVqUkZ6aTB0cHRvdFUyRlVycG9uM1IzL1ptOXNCdFRU?=
 =?utf-8?B?M0hoTFhKYnp4eEJoUlpCMmp2ZUw5TWFUc0xDQzY1T2g1WE1RUCtBRW9yVXhB?=
 =?utf-8?B?bXByMEsyR25LKzNnMVVua3QyZ2FWdFRqOHZSRlFjWG5KZ2FNSzlMeHh5em1E?=
 =?utf-8?B?QjNvcFFWV1hJaFlwTDhWaGpyMFJMTFpicGhBbGdlUWZaOHo1NWZFUGpxZTFC?=
 =?utf-8?B?NytlM0J5U09Vb3llMklwM3I0L0hvYnp5OE1kaDlLc0Zhd0c4NUVYL1ZNa2RP?=
 =?utf-8?B?S3FYcldZS3l5R3ZJaGNQVkFSTmx5ODF2c2YxWHZ6SktLYzdKNVRpYjBERXo0?=
 =?utf-8?B?TGxiMmxpeXpQRDFnc1hqNGhzeEFzdXlndjVGNTlSd3lYQXp4eGFodGVIUWc5?=
 =?utf-8?B?aGQxMFdBaWhFdTZyS3dMNzZSWVFPNVNQSi9NR3c0Q3pmbjc1M2J6NkZJMUNk?=
 =?utf-8?B?c3ZrQnZsaVMyRFByYkVsTC9pTmRIMWlCTEtzTGRocWtDbGxYcFRRKzdEV1FD?=
 =?utf-8?B?dFBpR2JDOVJXckhOVE0xUGd1TndyazRkNE10M0NUZ1RQcVAwME1EL3BIOXk3?=
 =?utf-8?B?Nm81TnllV080aUZsVXE1Q2RQUlZWQmJ3bGUwYzIvdGhRbkV3THBiWnJKRmpo?=
 =?utf-8?B?Y0M1dWFSVjhqSXBEdkNzdU81YmIvL1BzR2NGYXVRd3pnODB6alpVbW5Ldm9v?=
 =?utf-8?B?WFNOUEhqZ2ovT0hWaVppMEk1cnhrNGg4OEtJNisxOTA0K0dKZ3pjSVpZeVFO?=
 =?utf-8?B?UGtwYS8zYUJndXlRcmFMVW5DVnkyNXV2dHl1Y1RrRVpiNUhvalpST0V2OENJ?=
 =?utf-8?B?Q1dBd0U1SVRzNW9oNlUvTFJZbm9IOElxQTkvVzJmR2ZOdm50SDZGemp0NzRj?=
 =?utf-8?B?ZGVKdUJaenZVbXBZSkMvalo4cmg5dEhXOTlzOUtrSldBVDdMRUhuMjFpcFJW?=
 =?utf-8?B?d0xnRUFXbDlzUm9zYmVaWHlRYVFId004Vk1vbFBLejBsYlNENGhRcmtYbzNo?=
 =?utf-8?B?LzFtNUxlcXdQaWw0T3crOWtMS1pMTTlQM0FPTjdySVdVQkk0UlpWNVdKU1ZE?=
 =?utf-8?B?N3cvM1pRalFsSXRjMFZPTDJlUjVpZnA0UGdTRHN2UG5ES3E5Y3hFODA1NHM0?=
 =?utf-8?B?cWFOa2x4NGFGTWt4R3FhWU5MTkJncmdJQWZUdndCRDZzWXdLNEIrNmdKVmF0?=
 =?utf-8?B?aHpiUDM5Q2d4TE1xcG9ocm9Nd0lhQUdwc29zOVRRNkY4dTljYkt3SFRJTURR?=
 =?utf-8?B?OHltVHB1SUlCck5EbWZudS9Uc0FrYzEvaVd0a2E5YnlrRmJrb1ZadkV4Z1Ew?=
 =?utf-8?B?ZEs5R1dSSjBsYzJVRThGS1U0cjB0cCtTdkVpbnAwdy95ckF0Q3hyYURvSlJM?=
 =?utf-8?B?NnExQlU0YmJxWFZxbVpSMkpjTzNCcDFwMWh3QUtIbDBWSnNyV2NhdlJlOTdx?=
 =?utf-8?B?OEpaRDJXempxM3FOMHFIeXFJVkpOeEdsRW9jWU1VVnVLampMS2ZrT3lqTklI?=
 =?utf-8?B?RkdKSWZKaEx3cTZTMmhnZmdwMEhlT2NGRXMrMUk1RDZkRXEwcmRnZC9FVnE4?=
 =?utf-8?B?RG5RcFAzTkF2WGtORm5FUjlreExEOWdUTXNZR1JOZmZNUWxrQit6VGVKTHlE?=
 =?utf-8?B?cXVoVUdhQzZjYVBnM041V05sZm5saXBUQUVEV0w2UDZZNDRaKzgwOU5mZlE1?=
 =?utf-8?B?RlhsenEvMlJSUU5DOC9lUUU5QlpEUG44U2l3NEZOUHFNWDdWRWN0Sm1jU21J?=
 =?utf-8?B?b2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bbf45d9-3b09-4d51-a45d-08db4d996c53
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2023 18:49:14.8605
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eZSrMRN3d+w4DA9ooITK7LRI/LIceyNGPWd3XLsUGQ21hN1kg+ODwQM5vhRcJnl55MNR09TFfaN8bvlJsdXyCPlYQJkRbihv1muF/zhiZ70=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6517
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Babu,

On 5/5/2023 10:09 AM, Moger, Babu wrote:
> [AMD Official Use Only - General]
> 
> Hi Reinette,
> 
>> -----Original Message-----
>> From: Reinette Chatre <reinette.chatre@intel.com>
>> Sent: Thursday, May 4, 2023 1:58 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 v4 1/7] x86/resctrl: Add multiple tasks to the resctrl group
>> at once
>>
>> Hi Babu,
>>
>> On 4/17/2023 4:34 PM, Babu Moger wrote:
>>> The resctrl task assignment for MONITOR or CONTROL group needs to be
>>> done one at a time. For example:
>>
>> Why all caps for monitor and control? If the intention is to use the terms for
>> these groups then it may be easier to use the same terms as in the
>> documentation, or you could just not use all caps like you do in later patches.
> 
> Sure.
>>
>>>
>>>   $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.
>>>
>>> It can be improved by supporting the multiple task id assignment in
>>> one command with the tasks separated by commas. For example:
>>
>> Please use imperative mood (see Documentation/process/maintainer-tip.rst).
>>
>> Something like:
>> "Improve multiple task id assignment ...."
> 
> How about:
> "Improve the assignment by supporting multiple task id assignment in
> one command with the tasks separated by commas."

The double use of 'assignment' can be confusing. This is also a
changelog where a clear context->problem->solution format can help.
If your changelog is clear regarding the context and problem then it
can end with brief solution description like:

"Support multiple task assignment in one command with tasks ids separated
by commas. For example: " (and also please use a non-x86 term for the group
name in your example)

>>>   $echo 123,456,789 > /sys/fs/resctrl/clos1/tasks
>>>

...

>>> +	pid will be logged in /sys/fs/resctrl/info/last_cmd_status file.
>>
>> Would it not always print the failing pid (if error was encountered while
> 
> Not always. In this case it does not print the pid,
> rdt_last_cmd_puts("Can't move task to different control group\n");
>                         return -EINVAL;
> 

What you quote above adds the relevant text to the last_cmd_status buffer ...
and later (see below) more text is added to the buffer that contains the
pid, no?

...

>>>  	struct rdtgroup *rdtgrp;
>>> +	char *pid_str;
>>>  	int ret = 0;
>>>  	pid_t pid;
>>>
>>> -	if (kstrtoint(strstrip(buf), 0, &pid) || pid < 0)
>>> +	if (nbytes == 0)
>>>  		return -EINVAL;
>>> +
>>> +	buf[nbytes - 1] = '\0';
>>> +
>>
>> This seems like another remnant of the schemata write code that expects that
>> the buffer ends with a '\n'. Since this code does not have this requirement the
>> above may have unintended consequences if a tool provides a buffer that does
>> not end with '\n'.
>> I think you just want to ensure that the buffer is properly terminated and from
>> what I understand when looking at kernfs_fop_write_iter() this is already taken
>> care of.
> 
> Sure. Will check. Then I will have to change the check below to if (!buf).

Please check what kernfs_fop_write_iter() does. From what I can tell it does
exactly what you are trying to do above, but without overwriting
part of the string that user space provides.
I thus do not think that the later check needs to change. From what I understand
it is used to handle the scenario if user space provides a string like "pid,"
(last character is the separator). Please do confirm that the code can handle
any variations that user space may throw at it.

>>> @@ -716,6 +739,12 @@ static ssize_t rdtgroup_tasks_write(struct
>> kernfs_open_file *of,
>>>  	}
>>>
>>>  	ret = rdtgroup_move_task(pid, rdtgrp, of);
>>> +	if (ret) {
>>> +		rdt_last_cmd_printf("Error while processing task %d\n", pid);

Note here the pid is added to the buffer that is printed when user space
views last_cmd_status. I think this is the first time two lines of error may
be added to the buffer so you could double check all works as expected.

Reinette