From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Srivatsa S. Bhat" Subject: Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline Date: Wed, 26 Jun 2013 23:48:38 +0530 Message-ID: <51CB307E.9050508@linux.vnet.ibm.com> References: <20130625202452.16593.22810.stgit@srivatsabhat.in.ibm.com> <20130625202755.16593.67819.stgit@srivatsabhat.in.ibm.com> <20130625220026.GG3828@linux.vnet.ibm.com> <51CAF624.6060004@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from e23smtp08.au.ibm.com ([202.81.31.141]:36665 "EHLO e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752642Ab3FZSWO (ORCPT ); Wed, 26 Jun 2013 14:22:14 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Jun 2013 04:19:25 +1000 In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: David Laight Cc: paulmck@linux.vnet.ibm.com, peterz@infradead.org, fweisbec@gmail.com, linux-kernel@vger.kernel.org, walken@google.com, mingo@kernel.org, linux-arch@vger.kernel.org, vincent.guittot@linaro.org, xiaoguangrong@linux.vnet.ibm.com, wangyun@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org, rusty@rustcorp.com.au, rostedt@goodmis.org, namhyung@kernel.org, tglx@linutronix.de, laijs@cn.fujitsu.com, zhong@linux.vnet.ibm.com, netdev@vger.kernel.org, oleg@redhat.com, sbw@mit.edu, tj@kernel.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org On 06/26/2013 07:59 PM, David Laight wrote: >> Once stop_machine() is gone from the CPU offline path, we won't be able >> to depend on disabling preemption to prevent CPUs from going offline >> from under us. > > Could you use an rcu-like sequence so that disabling pre-emption > would be enough? > > Something like rebuilding the cpu list, then forcing yourself > to run on all the cpu. > Certainly, and we had debated schemes similar to that (including schemes invoking synchronize_sched() itself) in earlier discussions. (But IIRC even those schemes required converting call-sites from preempt_disable() to get/put_online_cpus_atomic(), to properly synchronize). > That would be far less intrusive. > But that would increase the latency of hotplug operations like Paul pointed out, and that in turn is not good for use-cases such as suspend/resume, where we take all non-boot CPUs offline in a loop. (That would mean executing the above logic num_online_cpus() times!). So we started hunting for ideas that can make the hotplug writer side not only less intrusive, but also remain fast. That's how the later designs evolved. Regards, Srivatsa S. Bhat From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e23smtp07.au.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 3906A2C0087 for ; Thu, 27 Jun 2013 04:22:33 +1000 (EST) Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Jun 2013 04:10:36 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id CA5762CE804D for ; Thu, 27 Jun 2013 04:22:07 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5QI77OV4522360 for ; Thu, 27 Jun 2013 04:07:07 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5QIM5cp021622 for ; Thu, 27 Jun 2013 04:22:06 +1000 Message-ID: <51CB307E.9050508@linux.vnet.ibm.com> Date: Wed, 26 Jun 2013 23:48:38 +0530 From: "Srivatsa S. Bhat" MIME-Version: 1.0 To: David Laight Subject: Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline References: <20130625202452.16593.22810.stgit@srivatsabhat.in.ibm.com> <20130625202755.16593.67819.stgit@srivatsabhat.in.ibm.com> <20130625220026.GG3828@linux.vnet.ibm.com> <51CAF624.6060004@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Cc: peterz@infradead.org, fweisbec@gmail.com, oleg@redhat.com, walken@google.com, mingo@kernel.org, linux-arch@vger.kernel.org, vincent.guittot@linaro.org, xiaoguangrong@linux.vnet.ibm.com, wangyun@linux.vnet.ibm.com, paulmck@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org, rusty@rustcorp.com.au, rostedt@goodmis.org, namhyung@kernel.org, tglx@linutronix.de, laijs@cn.fujitsu.com, zhong@linux.vnet.ibm.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, sbw@mit.edu, tj@kernel.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/26/2013 07:59 PM, David Laight wrote: >> Once stop_machine() is gone from the CPU offline path, we won't be able >> to depend on disabling preemption to prevent CPUs from going offline >> from under us. > > Could you use an rcu-like sequence so that disabling pre-emption > would be enough? > > Something like rebuilding the cpu list, then forcing yourself > to run on all the cpu. > Certainly, and we had debated schemes similar to that (including schemes invoking synchronize_sched() itself) in earlier discussions. (But IIRC even those schemes required converting call-sites from preempt_disable() to get/put_online_cpus_atomic(), to properly synchronize). > That would be far less intrusive. > But that would increase the latency of hotplug operations like Paul pointed out, and that in turn is not good for use-cases such as suspend/resume, where we take all non-boot CPUs offline in a loop. (That would mean executing the above logic num_online_cpus() times!). So we started hunting for ideas that can make the hotplug writer side not only less intrusive, but also remain fast. That's how the later designs evolved. Regards, Srivatsa S. Bhat