From: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> To: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> Cc: Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, npiggin-l3A5Bk7waGM@public.gmane.org, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mingo-X9Un+BFzKDI@public.gmane.org Subject: Re: [PATCH 2/10] x86: convert to generic helpers for IPI function calls Date: Wed, 30 Apr 2008 14:31:37 +0200 [thread overview] Message-ID: <20080430123136.GB12774@kernel.dk> (raw) In-Reply-To: <20080430122001.GS11126-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> On Wed, Apr 30 2008, Paul E. McKenney wrote: > On Wed, Apr 30, 2008 at 01:35:42PM +0200, Jens Axboe wrote: > > On Tue, Apr 29 2008, Jeremy Fitzhardinge wrote: > > > Jens Axboe wrote: > > > >-int xen_smp_call_function_mask(cpumask_t mask, void (*func)(void *), > > > >- void *info, int wait) > > > > > > > [...] > > > >- /* Send a message to other CPUs and wait for them to respond */ > > > >- xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR); > > > >- > > > >- /* Make sure other vcpus get a chance to run if they need to. */ > > > >- yield = false; > > > >- for_each_cpu_mask(cpu, mask) > > > >- if (xen_vcpu_stolen(cpu)) > > > >- yield = true; > > > >- > > > >- if (yield) > > > >- HYPERVISOR_sched_op(SCHEDOP_yield, 0); > > > > > > > > > > I added this to deal with the case where you're sending an IPI to > > > another VCPU which isn't currently running on a real cpu. In this case > > > you could end up spinning while the other VCPU is waiting for a real CPU > > > to run on. (Basically the same problem that spinlocks have in a virtual > > > environment.) > > > > > > However, this is at best a partial solution to the problem, and I never > > > benchmarked if it really makes a difference. Since any other virtual > > > environment would have the same problem, its best if we can solve it > > > generically. (Of course a synchronous single-target cross-cpu call is a > > > simple cross-cpu rpc, which could be implemented very efficiently in the > > > host/hypervisor by simply doing a vcpu context switch...) > > > > So, what would your advice be? Seems safe enough to ignore for now and > > attack it if it becomes a real problem. > > How about an arch-specific function/macro invoked in the spin loop? > The generic implementation would do nothing, but things like Xen > could implement as above. Xen could just stuff that bit into its arch_send_call_function_ipi(), something like the below should be fine. My question to Jeremy was more of the order of whether it should be kept or not, I guess it's safer to just keep it and retain the existing behaviour (and let Jeremy/others evaluate it at will later on). Note that I got rid of the yield bool and break when we called the hypervisor. Jeremy, shall I add this? diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 2dfe093..064e6dc 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -352,7 +352,17 @@ static void xen_send_IPI_mask(cpumask_t mask, enum ipi_vector vector) void xen_smp_send_call_function_ipi(cpumask_t mask) { + int cpu; + xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR); + + /* Make sure other vcpus get a chance to run if they need to. */ + for_each_cpu_mask(cpu, mask) { + if (xen_vcpu_stolen(cpu)) { + HYPERVISOR_sched_op(SCHEDOP_yield, 0); + break; + } + } } void xen_smp_send_call_function_single_ipi(int cpu) -- Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com> To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org, peterz@infradead.org, npiggin@suse.de, linux-arch@vger.kernel.org, mingo@elte.hu Subject: Re: [PATCH 2/10] x86: convert to generic helpers for IPI function calls Date: Wed, 30 Apr 2008 14:31:37 +0200 [thread overview] Message-ID: <20080430123136.GB12774@kernel.dk> (raw) Message-ID: <20080430123137.l-ouVgScbWbZnftD_RQa8gHsFQ17qq1yXUd5WLCLYgQ@z> (raw) In-Reply-To: <20080430122001.GS11126@linux.vnet.ibm.com> On Wed, Apr 30 2008, Paul E. McKenney wrote: > On Wed, Apr 30, 2008 at 01:35:42PM +0200, Jens Axboe wrote: > > On Tue, Apr 29 2008, Jeremy Fitzhardinge wrote: > > > Jens Axboe wrote: > > > >-int xen_smp_call_function_mask(cpumask_t mask, void (*func)(void *), > > > >- void *info, int wait) > > > > > > > [...] > > > >- /* Send a message to other CPUs and wait for them to respond */ > > > >- xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR); > > > >- > > > >- /* Make sure other vcpus get a chance to run if they need to. */ > > > >- yield = false; > > > >- for_each_cpu_mask(cpu, mask) > > > >- if (xen_vcpu_stolen(cpu)) > > > >- yield = true; > > > >- > > > >- if (yield) > > > >- HYPERVISOR_sched_op(SCHEDOP_yield, 0); > > > > > > > > > > I added this to deal with the case where you're sending an IPI to > > > another VCPU which isn't currently running on a real cpu. In this case > > > you could end up spinning while the other VCPU is waiting for a real CPU > > > to run on. (Basically the same problem that spinlocks have in a virtual > > > environment.) > > > > > > However, this is at best a partial solution to the problem, and I never > > > benchmarked if it really makes a difference. Since any other virtual > > > environment would have the same problem, its best if we can solve it > > > generically. (Of course a synchronous single-target cross-cpu call is a > > > simple cross-cpu rpc, which could be implemented very efficiently in the > > > host/hypervisor by simply doing a vcpu context switch...) > > > > So, what would your advice be? Seems safe enough to ignore for now and > > attack it if it becomes a real problem. > > How about an arch-specific function/macro invoked in the spin loop? > The generic implementation would do nothing, but things like Xen > could implement as above. Xen could just stuff that bit into its arch_send_call_function_ipi(), something like the below should be fine. My question to Jeremy was more of the order of whether it should be kept or not, I guess it's safer to just keep it and retain the existing behaviour (and let Jeremy/others evaluate it at will later on). Note that I got rid of the yield bool and break when we called the hypervisor. Jeremy, shall I add this? diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 2dfe093..064e6dc 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -352,7 +352,17 @@ static void xen_send_IPI_mask(cpumask_t mask, enum ipi_vector vector) void xen_smp_send_call_function_ipi(cpumask_t mask) { + int cpu; + xen_send_IPI_mask(mask, XEN_CALL_FUNCTION_VECTOR); + + /* Make sure other vcpus get a chance to run if they need to. */ + for_each_cpu_mask(cpu, mask) { + if (xen_vcpu_stolen(cpu)) { + HYPERVISOR_sched_op(SCHEDOP_yield, 0); + break; + } + } } void xen_smp_send_call_function_single_ipi(int cpu) -- Jens Axboe
next prev parent reply other threads:[~2008-04-30 12:31 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-04-29 7:26 [PATCH 0/10] Add generic helpers for arch IPI function calls #3 Jens Axboe 2008-04-29 7:26 ` Jens Axboe [not found] ` <1209453990-7735-1-git-send-email-jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2008-04-29 7:26 ` [PATCH 1/10] Add generic helpers for arch IPI function calls Jens Axboe 2008-04-29 7:26 ` Jens Axboe [not found] ` <1209453990-7735-2-git-send-email-jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2008-04-29 13:59 ` Paul E. McKenney 2008-04-29 13:59 ` Paul E. McKenney [not found] ` <20080429135936.GC12390-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 2008-04-30 11:29 ` Paul E. McKenney 2008-04-30 11:29 ` Paul E. McKenney [not found] ` <20080430112934.GA23203-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 2008-04-30 11:34 ` Jens Axboe 2008-04-30 11:34 ` Jens Axboe [not found] ` <20080430113456.GY12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> 2008-04-30 12:17 ` Paul E. McKenney 2008-04-30 12:17 ` Paul E. McKenney [not found] ` <20080430121712.GR11126-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 2008-04-30 12:37 ` Jens Axboe 2008-04-30 12:37 ` Jens Axboe [not found] ` <20080430123717.GC12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> 2008-05-01 2:44 ` Paul E. McKenney 2008-05-01 2:44 ` Paul E. McKenney 2008-05-02 2:02 ` Paul E. McKenney 2008-05-02 2:12 ` Nick Piggin 2008-05-02 12:29 ` Paul E. McKenney 2008-05-02 12:42 ` Paul E. McKenney 2008-05-02 12:59 ` Peter Zijlstra 2008-05-02 12:59 ` Peter Zijlstra 2008-05-02 14:21 ` Paul E. McKenney 2008-05-02 14:21 ` Paul E. McKenney 2008-05-03 2:30 ` Paul E. McKenney 2008-05-03 5:49 ` Nick Piggin 2008-05-03 18:11 ` Paul E. McKenney 2008-05-04 22:04 ` Paul E. McKenney 2008-05-05 4:15 ` Nick Piggin 2008-05-05 4:15 ` Nick Piggin 2008-05-05 17:43 ` Paul E. McKenney 2008-05-07 20:42 ` Jens Axboe 2008-05-08 4:36 ` Paul E. McKenney 2008-05-02 12:50 ` Keith Owens 2008-05-02 13:09 ` Paul E. McKenney 2008-04-30 22:56 ` Jeremy Fitzhardinge 2008-04-30 22:56 ` Jeremy Fitzhardinge 2008-04-29 7:26 ` [PATCH 2/10] x86: convert to generic helpers for " Jens Axboe 2008-04-29 7:26 ` Jens Axboe [not found] ` <1209453990-7735-3-git-send-email-jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2008-04-29 20:35 ` Jeremy Fitzhardinge 2008-04-29 20:35 ` Jeremy Fitzhardinge [not found] ` <481786A5.7010604-TSDbQ3PG+2Y@public.gmane.org> 2008-04-30 11:35 ` Jens Axboe 2008-04-30 11:35 ` Jens Axboe [not found] ` <20080430113542.GZ12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> 2008-04-30 12:20 ` Paul E. McKenney 2008-04-30 12:20 ` Paul E. McKenney [not found] ` <20080430122001.GS11126-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 2008-04-30 12:31 ` Jens Axboe [this message] 2008-04-30 12:31 ` Jens Axboe [not found] ` <20080430123136.GB12774-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> 2008-04-30 14:51 ` Jeremy Fitzhardinge 2008-04-30 14:51 ` Jeremy Fitzhardinge 2008-04-30 21:39 ` Jeremy Fitzhardinge 2008-04-30 21:39 ` Jeremy Fitzhardinge 2008-04-29 7:26 ` [PATCH 3/10] powerpc: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 4/10] ia64: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 5/10] alpha: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 6/10] arm: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 7/10] m32r: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 8/10] mips: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 9/10] parisc: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe 2008-04-29 7:26 ` [PATCH 10/10] sh: " Jens Axboe 2008-04-29 7:26 ` Jens Axboe -- strict thread matches above, loose matches on Subject: below -- 2008-05-29 8:58 [PATCH 0/10] Add generic helpers for arch IPI function calls #4 Jens Axboe 2008-05-29 8:58 ` [PATCH 2/10] x86: convert to generic helpers for IPI function calls Jens Axboe 2008-05-29 12:12 ` Jeremy Fitzhardinge 2008-05-29 12:17 ` Jens Axboe 2008-05-29 13:47 ` Jeremy Fitzhardinge
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=20080430123136.GB12774@kernel.dk \ --to=jens.axboe-qhclzuegtsvqt0dzr+alfa@public.gmane.org \ --cc=jeremy-TSDbQ3PG+2Y@public.gmane.org \ --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mingo-X9Un+BFzKDI@public.gmane.org \ --cc=npiggin-l3A5Bk7waGM@public.gmane.org \ --cc=paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \ --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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: linkBe 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).