From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AD17201113 for ; Fri, 22 May 2026 14:11:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779459077; cv=none; b=i4tJhbnA8k56a1R8gI6MCc7Dk8MNtxVoCBIVx+PlfVQ2OCCWb5cXIpIL5TXIuTdtJemU9aeXTt3kWlVdJMwWqQSePA1bgYKfoYXgCZ21HIt1d85aK6K6vNRGOChChrF81lWcvQ9OFG+FkY8GBcofJX6zwmITtuzBwl0vIvW78sY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779459077; c=relaxed/simple; bh=mYrIwAStpt0vGJs0ivXYB6oLhA5min4Mv8IXeD/anQY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=k6sQD8z/um1reJxNiT8Th2R+i7waO1dS3XfY0yI2ydnBBIDnQACA+i5/WUOoYInITvJupyWBjjr/Yw41A5ektSO2nUMqnyypaViSovCYfWKdBKhsJLYpypKz0m3OsQLdcwlaNHgNTMKUBtHb41w73Lb1x2ldUF/nMRDGCNtG/i4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf04.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E41FCC2ABB; Fri, 22 May 2026 14:11:04 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf04.hostedemail.com (Postfix) with ESMTPA id 1BA8C20027; Fri, 22 May 2026 14:11:02 +0000 (UTC) Date: Fri, 22 May 2026 10:11:25 -0400 From: Steven Rostedt To: Sebastian Andrzej Siewior Cc: Chuyi Zhou , tglx@linutronix.de, mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com, clrkwllms@kernel.org, nadav.amit@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH v5 00/12] Allow preemption during IPI completion waiting to improve real-time performance Message-ID: <20260522101125.57074cd5@gandalf.local.home> In-Reply-To: <20260522105704.Vd1FdOA_@linutronix.de> References: <20260513124524.2569867-1-zhouchuyi@bytedance.com> <20260522105704.Vd1FdOA_@linutronix.de> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1BA8C20027 X-Rspamd-Server: rspamout06 X-Stat-Signature: 9nfdo8n38b84amzkns75a6ydbnhesj79 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX19j8rlvR9419aZ22oK2XZ8qO09jQLg8R1I= X-HE-Tag: 1779459062-556631 X-HE-Meta: U2FsdGVkX18D17assk/5Tjc4qwCbWP5pjAV01EFqUqAzx/h2FNCffBps8QVgpznNUtr3Nv8LAct1LwUU0Jg9nNLdOyH1bhWU/okfLyXbeSUmml2iwEuXVxy2hFIa9tFcR07DV243N/Lc6EBYdD6quefxxyudHsPw8Hrq/8o9VOxQSW/i4idFCIIlF3eYe8/6xwmzY2SZGKtYorjH5+wkqzntW2vlB9tO4jNVD8WrZofDf0RqPrzDhhSXffeLH7QaC/9tOm05/C3IgpuICIluMATNBna9I6ei54gGjiM4Dw2c79vLbJebjAcZZx/zLy6dM1M7xWTcowcTkx0nfk80SiuUUGvmyq4r55bBXEgD/i5cpFBSiAi+r7Zy0AX7Mhf4pJff327POiSXWNlYUZDzkw== On Fri, 22 May 2026 12:57:04 +0200 Sebastian Andrzej Siewior wrote: > On 2026-05-13 20:45:12 [+0800], Chuyi Zhou wrote: > > Introduction > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > The vast majority of smp_call_function*() callers block until remote CP= Us > > complete the IPI function execution. As smp_call_function*() runs with > > preemption disabled throughout, scheduling latency increases dramatical= ly > > with the number of remote CPUs and other factors (such as interrupts be= ing > > disabled). =20 > =E2=80=A6 >=20 > Thank you for working on this. > I went through the series and I don't see anything wrong with it > conceptionally. I made a few comments on how to get > smp_call_function_many_cond() a bit improved/ readable but this is about > it. >=20 > For 1-3, 6-12: > Reviewed-by: Sebastian Andrzej Siewior >=20 > I am not too keen about that smp_processor_id() change, not sure if > flush_tlb_kernel_range() could get its own structure. Don't want to make > this series too complicated, that is the call of the x86 folks here. >=20 Sashiko may have found some minor issues too: https://sashiko.dev/#/patchset/20260513124524.2569867-1-zhouchuyi%40byted= ance.com Thanks, -- Steve