Received-SPF: pass (google.com: domain of linux-kernel+bounces-154183-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <240e09fb-257f-d32c-64c8-559430b06a2a@oracle.com>
Date: Mon, 22 Apr 2024 16:09:02 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 1/1] genirq/cpuhotplug: retry with online CPUs on
 irq_do_set_affinity failure
To: Thomas Gleixner <tglx@linutronix.de>
Cc: virtualization@lists.linux.dev, joe.jin@oracle.com,
        linux-kernel@vger.kernel.org
References: <20240419013322.58500-1-dongli.zhang@oracle.com>
 <20240419013322.58500-2-dongli.zhang@oracle.com> <87ttjtunbx.ffs@tglx>
Content-Language: en-US
From: Dongli Zhang <dongli.zhang@oracle.com>
In-Reply-To: <87ttjtunbx.ffs@tglx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?VERad0tqTHh5bzY4emhkOG5rbTJiR0QrZGVvOWRwYy9jVnh0UFpoQ3NRL0No?=
 =?utf-8?B?ajMvaGRwZmZRWFhRWllvUHNaZjZsWmNDcTRjMWsrMCsrU0R2blV5b2VkM0FN?=
 =?utf-8?B?N09Sd0VFZk9VTDV6YzhyN2lQd0daWE52RXNGbjlVRjRnT2RRQk0rVXJGT3R1?=
 =?utf-8?B?V1RpNlB6aWxvT3lrL2xwOEptOXZrY3BySU1JeGZKRXNNdVZ5ZFF6R1Jqb0tH?=
 =?utf-8?B?ZDV3S0xWd2V4YXVZamE4NkNaU2ZFVkxtdlVzN2czWllHTnUrTDEwWTlLenRi?=
 =?utf-8?B?Sm1LLzkyTHVqdTNjZDZCY3dPUUd1SnBmM0tzTVdGcnpjZmtTb3lRdlp0ZWZL?=
 =?utf-8?B?bWxldGsxVkNlWmliYlNQMzdaWDhMSnYxalh3SVFKOUsyWWZ1cktnZTlJL2ZJ?=
 =?utf-8?B?OTFaNXp2S2pwUzNWbzRqcDRrV2RDVURQZ1JQaU8xUkNEU0oxNE5yanpkTjd4?=
 =?utf-8?B?Ym43Y093c3ZORmFPNHlENGxReFNCSnRPVHhOV2ZIMFoyNDdxYVdEY0FyNU9E?=
 =?utf-8?B?TjQ3S3hIQ2ZaOVpsQ1NzRjlFV25QSWdCZzIvclZ2UkFNTGpMSVpVazZyUlE0?=
 =?utf-8?B?YTEwbXNtWWpEMm12eUtqSkRKSXRGVVRyeDZRSE13WHNLMk0vMjF6Skk0Q1BZ?=
 =?utf-8?B?UTZvNmJ4VGRLUEJFS2I0SnhrbFVYL2hlS3FPNi8vNDVNV1hEZUhPWlFIS1RL?=
 =?utf-8?B?cWRvd0Vma1dMMDVidnhnNmdYMmNXOWtHZEdkdXhycmZtNzR2MkZEcVZpVUJC?=
 =?utf-8?B?MjVuUGVPUTk2NVhyM0dVRFFwUWorVTVtdVVYaTcwQkFSZGFMeWRHa20zT285?=
 =?utf-8?B?dUxabzZaK0NVWHl6cGU1Y0lzWU1IbTlqQXp3dFpWbjdZcEkxR3pJZlJpVmxt?=
 =?utf-8?B?SXNaWGtRektVNzJOaGxkUTRRaFBxeXo2cVl1SGkvdjg4STV4SFdIanQzMm1I?=
 =?utf-8?B?aFArdU5aSlk3N2crVXJLUnQyRUVmS3Y4T3F0dms3QmRubTZDQmdvL2kzc3R3?=
 =?utf-8?B?UnR1RGJmT0lxbWhNR0VxbElHMHdxbWxhUVo2bG5wTGhsU3NyRUJETDdRNkVW?=
 =?utf-8?B?Vk9VWTRxaUJSNmRkbGJzbTczaGJiczhpcjJoYkJzaGFYQTZXSnBJNFNjVnlJ?=
 =?utf-8?B?WFFKWlpHckhucWswbVBtU0F1dXJrM1V3TnZBMi9UU29TRnJ1bDM4REgyWmp5?=
 =?utf-8?B?ZXZYMHNtTzZVU012bFA1WnBxWXFPYVI2cFZXMTM1dU1kVXRmc2liRDVwT2xK?=
 =?utf-8?B?M1pnZFhORVhXZ3ZncGlvSSs4b3dvVnpwZTRmd0hpUDFaVk00QWk4eHFVUlMv?=
 =?utf-8?B?UmQzblFOWUZyNlM2cmtTR1dlNnhCSmRjTHZsMnJONkpid09aVjZtYmRNNUxD?=
 =?utf-8?B?WmxGc2s4eUt0S214dVBFK0dTeVhiVVVZcjlLYnVxQmxTTk93by9INndGWms0?=
 =?utf-8?B?YldTWktJbDNUNHNLUXk2K0pzQzM2dmFzb3d4c1hPTm8wZWQzbnB2MTUxTXdM?=
 =?utf-8?B?VjRrSHJSdngwYXpvN09waEl1Y0RHM042eGx5Q3dTS0lSK3Z2d2ZyUXR1SW9v?=
 =?utf-8?B?bXlaS0pmMHNMU0gxNjFtQ1R2UUY1aTVGZVo5TW9OUmlBeVNkZ1daZHNneGlI?=
 =?utf-8?B?aUNSanN1aHEzVVFGc1ZieXdkb2d1U3FILytra3F3NEt3UGN1cWxKQnpvbi94?=
 =?utf-8?B?ZkVEWUp5MkZzOTQwZ2dUaGVWY05uZWlmT1lQU0RRNTN3OS9KSG1KdnZ4UXFC?=
 =?utf-8?B?TTdrR2VYaFlXZkRJaVNnVng2US91ZFpLTm9lVTJPK1FaZ2xQSGozVGhuYmFp?=
 =?utf-8?B?UWI2SkV5dDNxaU1RNUlmWURtL3hrdUE4NDRINEdibXh3VGUvU21DK0tUZGcv?=
 =?utf-8?B?cElPRkdyT2FnRW5KUW92ZUtqRVpXbHpSVitHU1VXT04rdFhQdk9RNzBvcXBO?=
 =?utf-8?B?bWtWWkFBYXhFOG1FWjI3RnAxMzduWlRoZjVyL1hGTWlYQlkzUXFicDZKMnpH?=
 =?utf-8?B?eFFFTGFGWmRYVHArSDRzb1IwM3pqa1ZPU1o1alBvQTZacEMxNU9iQ3g2U01J?=
 =?utf-8?B?aTNPbzhmbHJoWkJIR1lTR3ZMNlRFYWFqY2U2RnZBVzdHczdoSU9uMERqSWlm?=
 =?utf-8?Q?2XsOJ52y4Bsy7Tcr+YWpvU0/W?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	9kI17MkV6FjkR/7zBkL0nxeko7HjRubya+AUq+G+ncLndn6Bz4uurgNbegoD8djIGpFM3niqvY8jzCwzvOMn+Yk/4hNiPfHNcW7S4cmrrhcvaD5T9PgLgagSstfStYOlp+StHiUsQgqJRxSSxVUc28BLH+Uc4M3UkRRCTYcQcH6FFygx9n0KkFjCBzxkiQuwM7Vqi3dGMMLJ+AUoHKaHil5UuvFDFqqwtKA8knFJjgfFyqRX4sxop2qBmDk6bbMV8k6DN+OuzUOEp6Vj+m5rUQEcAGlb2KYuxTXWbPF2s+Len1PAULeNZEsR98Q8QRQ+1lCBUDX2JMjr10qEJ3mxhN7C5wNNrHgV+ZF6zWeo9jniqut8ITFNdmEi0H+6BlqKYeFy/mljNW0FKuEw2UhsEHq5ksU/rzIGm4ALnxk+nY1u6in40il4d1v+C8yLVTixfYj3WuRZvO7uHYBV0/TllVI6grVAnXadNHYJb+uYdN4os4hyt7zSe213xA1G37uKLnpNsXqH6wN9RFZ6AHOGhWQOuK0iO9/GFB2Kx9N+T0HQ6AdyXduZ1FE8aE2FB4fYg+lYlMv+jZzN8j9OqyMfjM39CBoBYGe+MQ6YGXbNfl0=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b40f5e9f-bc36-4e7d-e640-08dc632134e6
X-MS-Exchange-CrossTenant-AuthSource: SA0PR10MB6425.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2024 23:09:05.3665
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Z/9p8HdXmHcGxp3fJ7DXDCtqTsbX4WnY71xASKXiTHh5ytWW/sdkQfYZS9DJFOvsSHlVC0kEutnFjxcvxiqaRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB4821
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-04-22_16,2024-04-22_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999
 bulkscore=0 mlxscore=0 suspectscore=0 adultscore=0 malwarescore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2404010000 definitions=main-2404220096
X-Proofpoint-ORIG-GUID: EgK-J-hR7VOlb-31Lb_vh8kklhHxgdJY
X-Proofpoint-GUID: EgK-J-hR7VOlb-31Lb_vh8kklhHxgdJY

Hi Thomas,

On 4/22/24 13:58, Thomas Gleixner wrote:
> On Thu, Apr 18 2024 at 18:33, Dongli Zhang wrote:
> 
>> When a CPU is offline, its IRQs may migrate to other CPUs. For managed
>> IRQs, they are migrated, or shutdown (if all CPUs of the managed IRQ
>> affinity are offline). For regular IRQs, there will only be a
>> migration.
> 
> Please write out interrupts. There is enough space for it and IRQ is
> just not a regular word.

I will use "interrupts".

> 
>> The migrate_one_irq() first uses pending_mask or affinity_mask of the IRQ.
>>
>> 104         if (irq_fixup_move_pending(desc, true))
>> 105                 affinity = irq_desc_get_pending_mask(desc);
>> 106         else
>> 107                 affinity = irq_data_get_affinity_mask(d);
>>
>> The migrate_one_irq() may use all online CPUs, if all CPUs in
>> pending_mask/affinity_mask are already offline.
>>
>> 113         if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
>> 114                 /*
>> 115                  * If the interrupt is managed, then shut it down and leave
>> 116                  * the affinity untouched.
>> 117                  */
>> 118                 if (irqd_affinity_is_managed(d)) {
>> 119                         irqd_set_managed_shutdown(d);
>> 120                         irq_shutdown_and_deactivate(desc);
>> 121                         return false;
>> 122                 }
>> 123                 affinity = cpu_online_mask;
>> 124                 brokeaff = true;
>> 125         }
> 
> Please don't copy code into the change log. Describe the problem in
> text.

Would you mind suggesting if the below commit message is fine to you?


genirq/cpuhotplug: retry with cpu_online_mask when irq_do_set_affinity return
-ENOSPC

When a CPU goes offline, the interrupts pinned to that CPU are
re-configured.

Its managed interrupts undergo either migration to other CPUs or shutdown
if all CPUs listed in the affinity are offline. This patch doesn't affect
managed interrupts.

For regular interrupts, they are migrated to other selected online CPUs.
The target CPUs are chosen from either desc->pending_mask (suppose
CONFIG_GENERIC_PENDING_IRQ) or d->common->affinity (suppose CONFIG_SMP).
The cpu_online_mask is used as target CPUs only when CPUs in both
desc->pending_mask and d->common->affinity are offline.

However, there is a bad corner case, when desc->pending_mask or
d->common->affinity is selected as the target cpumask, but none of their
CPUs has any available vectors.

As a result, an -ENOSPC error happens:

  "IRQ151: set affinity failed(-28)."

This is from the debugfs. The allocation fails although other online CPUs
(except CPU=2) have many free vectors.

name:   VECTOR
 size:   0
 mapped: 529
 flags:  0x00000103
Online bitmaps:        7
Global available:    884
Global reserved:       6
Total allocated:     539
System: 36: 0-19,21,50,128,236,243-244,246-255
 | CPU | avl | man | mac | act | vectors
     0   147     0     0   55  32-49,51-87
     1   147     0     0   55  32-49,51-87
     2     0     0     0  202  32-49,51-127,129-235
     4   147     0     0   55  32-49,51-87
     5   147     0     0   55  32-49,51-87
     6   148     0     0   54  32-49,51-86
     7   148     0     0   54  32-49,51-86

The steps to reproduce the issue are in [1]. The core idea is:

1. Create a KVM guest with many virtio-net PCI devices, each configured
with a very large number of queues/vectors.

2. Set the affinity of all virtio-net interrupts to "2,3".

3. Offline many CPUs, excluding "2,3".

4. Offline CPU=2, and irq_do_set_affinity() returns -ENOSPC.

For regular interrupts, if irq_do_set_affinity() returns -ENOSPC, retry it
with all online CPUs. The issue does not happen for managed interrupts
because the vectors are always reserved (in cm->managed_map) before the CPU
offline operation.

[1] https://lore.kernel.org/all/20240419013322.58500-1-dongli.zhang@oracle.com/

Cc: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>


> 
>> However, there is a corner case. Although some CPUs in
>> pending_mask/affinity_mask are still online, they are lack of available
>> vectors. If the kernel continues calling irq_do_set_affinity() with those CPUs,
>> there will be -ENOSPC error.
>>
>> This is not reasonable as other online CPUs still have many available
>> vectors.
> 
> Reasonable is not the question here. It's either correct or not.

This has been re-written in the new commit message.

> 
>> name:   VECTOR
>>  size:   0
>>  mapped: 529
>>  flags:  0x00000103
>> Online bitmaps:        7
>> Global available:    884
>> Global reserved:       6
>> Total allocated:     539
>> System: 36: 0-19,21,50,128,236,243-244,246-255
>>  | CPU | avl | man | mac | act | vectors
>>      0   147     0     0   55  32-49,51-87
>>      1   147     0     0   55  32-49,51-87
>>      2     0     0     0  202  32-49,51-127,129-235
> 
> Just ouf of curiousity. How did this end up with CPU2 completely
> occupied?

The details are in the link:
https://lore.kernel.org/all/20240419013322.58500-1-dongli.zhang@oracle.com/

Here is the core idea:

1. Create a KVM guest with many virtio-net PCI devices, each configured
with a very large number of queues/vectors.

2. Set the affinity of all virtio-net interrupts to "2,3".

3. Offline many CPUs, excluding "2,3".

4. Offline CPU=2, and irq_do_set_affinity() returns -ENOSPC.

> 
>>      4   147     0     0   55  32-49,51-87
>>      5   147     0     0   55  32-49,51-87
>>      6   148     0     0   54  32-49,51-86
>>      7   148     0     0   54  32-49,51-86
>>
>> This issue should not happen for managed IRQs because the vectors are already
>> reserved before CPU hotplug.
> 
> Should not? It either does or it does not.

It is "does not". I will fix it. Please see new commit message.

> 
>> For regular IRQs, do a re-try with all online
>> CPUs if the prior irq_do_set_affinity() is failed with -ENOSPC.
>>
>> Cc: Joe Jin <joe.jin@oracle.com>
>> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
>> ---
>>  kernel/irq/cpuhotplug.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
>> index 1ed2b1739363..d1666a6b73f4 100644
>> --- a/kernel/irq/cpuhotplug.c
>> +++ b/kernel/irq/cpuhotplug.c
>> @@ -130,6 +130,19 @@ static bool migrate_one_irq(struct irq_desc *desc)
>>  	 * CPU.
>>  	 */
>>  	err = irq_do_set_affinity(d, affinity, false);
>> +
>> +	if (err == -ENOSPC &&
>> +	    !irqd_affinity_is_managed(d) &&
>> +	    affinity != cpu_online_mask) {
> 
> This really wants to be a single line conditional.

I will change it to a single line.

Would you mind suggesting which is preferred? !cpumask_equal(affinity,
cpu_online_mask) or (affinity != cpu_online_mask)?


> 
>> +		affinity = cpu_online_mask;
>> +		brokeaff = true;
>> +
>> +		pr_debug("IRQ%u: set affinity failed for %*pbl, re-try with all online CPUs\n",
>> +			 d->irq, cpumask_pr_args(affinity));
> 
> How is it useful to print cpu_online_mask here?

My bad and sorry about that. I should print the log before changing 'affinity' I
will fix that in the new version.


Thank you very much for feedback!

Dongli Zhang