From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B71E2C433DB for ; Mon, 29 Mar 2021 11:04:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 927946195B for ; Mon, 29 Mar 2021 11:04:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231784AbhC2LDf (ORCPT ); Mon, 29 Mar 2021 07:03:35 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:15382 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232053AbhC2LDQ (ORCPT ); Mon, 29 Mar 2021 07:03:16 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4F88lc5xc7zlW22; Mon, 29 Mar 2021 19:01:32 +0800 (CST) Received: from [10.174.187.192] (10.174.187.192) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Mon, 29 Mar 2021 19:03:03 +0800 Subject: Re: [RFC PATCH 3/3] arm/arm64: Use gic_ipi_send_single() to inject single IPI To: Marc Zyngier CC: , , , , , References: <20210329085210.11524-1-wangjingyi11@huawei.com> <20210329085210.11524-4-wangjingyi11@huawei.com> <87v99aqnmg.wl-maz@kernel.org> From: Jingyi Wang Message-ID: <1476b457-f23c-1913-05c5-3a9b13319f6b@huawei.com> Date: Mon, 29 Mar 2021 19:03:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <87v99aqnmg.wl-maz@kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.187.192] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/29/2021 6:07 PM, Marc Zyngier wrote: > On Mon, 29 Mar 2021 09:52:10 +0100, > Jingyi Wang wrote: >> >> Currently, arm use gic_ipi_send_mask() to inject single IPI, which >> make the procedure a little complex. We use gic_ipi_send_single() >> instead as some other archs. >> >> Signed-off-by: Jingyi Wang >> --- >> arch/arm/kernel/smp.c | 16 +++++++++++++--- >> arch/arm64/kernel/smp.c | 16 +++++++++++++--- >> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c >> index 74679240a9d8..369ce529cdd8 100644 >> --- a/arch/arm/kernel/smp.c >> +++ b/arch/arm/kernel/smp.c >> @@ -534,6 +534,8 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = { >> }; >> >> static void smp_cross_call(const struct cpumask *target, unsigned int ipinr); >> +static void smp_cross_call_single(const struct cpumask *target, int cpu, >> + unsigned int ipinr); > > Why does this function need to take both a cpumask *and* a cpu, given > that they represent the same thing? > I was intended to use the extra param to reuse trace_ipi_raise_rcuidle. >> >> void show_ipi_list(struct seq_file *p, int prec) >> { >> @@ -564,14 +566,15 @@ void arch_send_wakeup_ipi_mask(const struct cpumask *mask) >> >> void arch_send_call_function_single_ipi(int cpu) >> { >> - smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC); >> + smp_cross_call_single(cpumask_of(cpu), cpu, IPI_CALL_FUNC); >> } >> >> #ifdef CONFIG_IRQ_WORK >> void arch_irq_work_raise(void) >> { >> + int cpu = smp_processor_id(); >> if (arch_irq_work_has_interrupt()) >> - smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK); >> + smp_cross_call(cpumask_of(cpu), cpu, IPI_IRQ_WORK); > > Why isn't that a call to smp_cross_call_single()? > I ignored that, thanks. >> } >> #endif >> >> @@ -707,6 +710,13 @@ static void smp_cross_call(const struct cpumask *target, unsigned int ipinr) >> __ipi_send_mask(ipi_desc[ipinr], target); >> } >> >> +static void smp_cross_call_single(const struct cpumask *target, int cpu, >> + unsigned int ipinr) >> +{ >> + trace_ipi_raise_rcuidle(target, ipi_types[ipinr]); > > Why don't you compute the cpumask here^^? > >> + __ipi_send_single(ipi_desc[ipinr], cpu); >> +} >> + >> static void ipi_setup(int cpu) >> { >> int i; >> @@ -744,7 +754,7 @@ void __init set_smp_ipi_range(int ipi_base, int n) >> >> void smp_send_reschedule(int cpu) >> { >> - smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE); >> + smp_cross_call_single(cpumask_of(cpu), cpu, IPI_RESCHEDULE); >> } >> >> void smp_send_stop(void) >> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c >> index 357590beaabb..d290b6dc5a6e 100644 >> --- a/arch/arm64/kernel/smp.c >> +++ b/arch/arm64/kernel/smp.c > > Similar comments for the arm64 side. > > Overall, this needs to be backed by data that indicates that there is > an actual benefit for this extra complexity. > > Thanks, > > M. > Firstly, I implemented exitless-IPIs to reduce VM trap caused by sending IPI as what x86 does here: https://patchwork.kernel.org/project/kvm/cover/1532327996-17619-1-git-send-email-wanpengli@tencent.com/ Then I realized that sending ipi mask usually cause sending IPIs all but self as IRM bit defines. So do you think we can use IRM if we can avoid extra cost like computing mask, or using broadcast IPIs is just meaningless for now? Thanks, Jingyi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1ABAC433C1 for ; Mon, 29 Mar 2021 18:56:58 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7E9746044F for ; Mon, 29 Mar 2021 18:56:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E9746044F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:CC:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EBc11JEkbVfMsMRdlsariVBITmyS70WBcYApvbqUpyY=; b=MVzo2jhmh3Hbjn6wIw7cO3uKD ZRO7Xwy6w2rWKxNFzAd8b+gmFxBijV6ji4fXr+ClQIalQqEbWbH9XqGz5/TnMfnJ3nTYAUkBXYN53 ng2OQ3Xy2wvKOAqdqWyxy28wQv3rY0SAsJwwKGzQ6mFbxcnXWx/N4NoR2eifJfUFOpX+C5khgBIUO S8dRmeGiBy07XnFHULlMiamZWjLNo5V10gjV+GUzWCTxQgLlr0UvdvZtISKhcZbdTSjXJOv1pWtMP okSm3VxQ4P71JVEBdkIoIngtECvfzHirret3mQHnfy5LjdpNh7iehfkN6ZMmkyo6uVHyFzc9i0hkq kzSJ/5rBA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lQx16-0018NS-Ar; Mon, 29 Mar 2021 18:53:38 +0000 Received: from szxga06-in.huawei.com ([45.249.212.32]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lQpfy-000bJ6-HW for linux-arm-kernel@lists.infradead.org; Mon, 29 Mar 2021 11:03:21 +0000 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4F88lc5xc7zlW22; Mon, 29 Mar 2021 19:01:32 +0800 (CST) Received: from [10.174.187.192] (10.174.187.192) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Mon, 29 Mar 2021 19:03:03 +0800 Subject: Re: [RFC PATCH 3/3] arm/arm64: Use gic_ipi_send_single() to inject single IPI To: Marc Zyngier CC: , , , , , References: <20210329085210.11524-1-wangjingyi11@huawei.com> <20210329085210.11524-4-wangjingyi11@huawei.com> <87v99aqnmg.wl-maz@kernel.org> From: Jingyi Wang Message-ID: <1476b457-f23c-1913-05c5-3a9b13319f6b@huawei.com> Date: Mon, 29 Mar 2021 19:03:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <87v99aqnmg.wl-maz@kernel.org> Content-Language: en-US X-Originating-IP: [10.174.187.192] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210329_120319_109542_B6FF3C5E X-CRM114-Status: GOOD ( 21.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/29/2021 6:07 PM, Marc Zyngier wrote: > On Mon, 29 Mar 2021 09:52:10 +0100, > Jingyi Wang wrote: >> >> Currently, arm use gic_ipi_send_mask() to inject single IPI, which >> make the procedure a little complex. We use gic_ipi_send_single() >> instead as some other archs. >> >> Signed-off-by: Jingyi Wang >> --- >> arch/arm/kernel/smp.c | 16 +++++++++++++--- >> arch/arm64/kernel/smp.c | 16 +++++++++++++--- >> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c >> index 74679240a9d8..369ce529cdd8 100644 >> --- a/arch/arm/kernel/smp.c >> +++ b/arch/arm/kernel/smp.c >> @@ -534,6 +534,8 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = { >> }; >> >> static void smp_cross_call(const struct cpumask *target, unsigned int ipinr); >> +static void smp_cross_call_single(const struct cpumask *target, int cpu, >> + unsigned int ipinr); > > Why does this function need to take both a cpumask *and* a cpu, given > that they represent the same thing? > I was intended to use the extra param to reuse trace_ipi_raise_rcuidle. >> >> void show_ipi_list(struct seq_file *p, int prec) >> { >> @@ -564,14 +566,15 @@ void arch_send_wakeup_ipi_mask(const struct cpumask *mask) >> >> void arch_send_call_function_single_ipi(int cpu) >> { >> - smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC); >> + smp_cross_call_single(cpumask_of(cpu), cpu, IPI_CALL_FUNC); >> } >> >> #ifdef CONFIG_IRQ_WORK >> void arch_irq_work_raise(void) >> { >> + int cpu = smp_processor_id(); >> if (arch_irq_work_has_interrupt()) >> - smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK); >> + smp_cross_call(cpumask_of(cpu), cpu, IPI_IRQ_WORK); > > Why isn't that a call to smp_cross_call_single()? > I ignored that, thanks. >> } >> #endif >> >> @@ -707,6 +710,13 @@ static void smp_cross_call(const struct cpumask *target, unsigned int ipinr) >> __ipi_send_mask(ipi_desc[ipinr], target); >> } >> >> +static void smp_cross_call_single(const struct cpumask *target, int cpu, >> + unsigned int ipinr) >> +{ >> + trace_ipi_raise_rcuidle(target, ipi_types[ipinr]); > > Why don't you compute the cpumask here^^? > >> + __ipi_send_single(ipi_desc[ipinr], cpu); >> +} >> + >> static void ipi_setup(int cpu) >> { >> int i; >> @@ -744,7 +754,7 @@ void __init set_smp_ipi_range(int ipi_base, int n) >> >> void smp_send_reschedule(int cpu) >> { >> - smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE); >> + smp_cross_call_single(cpumask_of(cpu), cpu, IPI_RESCHEDULE); >> } >> >> void smp_send_stop(void) >> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c >> index 357590beaabb..d290b6dc5a6e 100644 >> --- a/arch/arm64/kernel/smp.c >> +++ b/arch/arm64/kernel/smp.c > > Similar comments for the arm64 side. > > Overall, this needs to be backed by data that indicates that there is > an actual benefit for this extra complexity. > > Thanks, > > M. > Firstly, I implemented exitless-IPIs to reduce VM trap caused by sending IPI as what x86 does here: https://patchwork.kernel.org/project/kvm/cover/1532327996-17619-1-git-send-email-wanpengli@tencent.com/ Then I realized that sending ipi mask usually cause sending IPIs all but self as IRM bit defines. So do you think we can use IRM if we can avoid extra cost like computing mask, or using broadcast IPIs is just meaningless for now? Thanks, Jingyi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel