From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932621Ab3BSKn7 (ORCPT ); Tue, 19 Feb 2013 05:43:59 -0500 Received: from mx0.aculab.com ([213.249.233.131]:42284 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932549Ab3BSKn4 convert rfc822-to-8bit (ORCPT ); Tue, 19 Feb 2013 05:43:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context Date: Tue, 19 Feb 2013 10:42:53 -0000 Message-ID: In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context Thread-Index: Ac4Oh46eRPshRGTaQ5WguP6C41i24AABWy2w References: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com> <20130218123920.26245.56709.stgit@srivatsabhat.in.ibm.com> <51225A36.40600@linux.vnet.ibm.com> <51227810.6090009@linux.vnet.ibm.com> <51234C23.2030909@linux.vnet.ibm.com> From: "David Laight" To: "Srivatsa S. Bhat" , "Michel Lespinasse" Cc: , , , , , , , , , , , , , , , , , , , , , , , , Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I wouldn't go that far... ;-) Unfairness is not a show-stopper right? > IMHO, the warning/documentation should suffice for anybody wanting to > try out this locking scheme for other use-cases. I presume that by 'fairness' you mean 'write preference'? I'd not sure how difficult it would be, but maybe have two functions for acquiring the lock for read, one blocks if there is a writer waiting, the other doesn't. That way you can change the individual call sites separately. The other place I can imagine a per-cpu rwlock being used is to allow a driver to disable 'sleep' or software controlled hardware removal while it performs a sequence of operations. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David Laight" Subject: RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context Date: Tue, 19 Feb 2013 10:42:53 -0000 Message-ID: References: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com> <20130218123920.26245.56709.stgit@srivatsabhat.in.ibm.com> <51225A36.40600@linux.vnet.ibm.com> <51227810.6090009@linux.vnet.ibm.com> <51234C23.2030909@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT Return-path: Received: from mx0.aculab.com ([213.249.233.131]:42276 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932518Ab3BSKnz convert rfc822-to-8bit (ORCPT ); Tue, 19 Feb 2013 05:43:55 -0500 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07329-03 for ; Tue, 19 Feb 2013 10:43:52 +0000 (GMT) Content-class: urn:content-classes:message In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Srivatsa S. Bhat" , Michel Lespinasse Cc: tglx@linutronix.de, peterz@infradead.org, tj@kernel.org, oleg@redhat.com, paulmck@linux.vnet.ibm.com, rusty@rustcorp.com.au, mingo@kernel.org, akpm@linux-foundation.org, namhyung@kernel.org, rostedt@goodmis.org, wangyun@linux.vnet.ibm.com, xiaoguangrong@linux.vnet.ibm.com, rjw@sisk.pl, sbw@mit.edu, fweisbec@gmail.com, linux@arm.linux.org.uk, nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, vincent.guittot@linaro.org > I wouldn't go that far... ;-) Unfairness is not a show-stopper right? > IMHO, the warning/documentation should suffice for anybody wanting to > try out this locking scheme for other use-cases. I presume that by 'fairness' you mean 'write preference'? I'd not sure how difficult it would be, but maybe have two functions for acquiring the lock for read, one blocks if there is a writer waiting, the other doesn't. That way you can change the individual call sites separately. The other place I can imagine a per-cpu rwlock being used is to allow a driver to disable 'sleep' or software controlled hardware removal while it performs a sequence of operations. David From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ozlabs.org (Postfix) with SMTP id 9003B2C0077 for ; Tue, 19 Feb 2013 21:44:01 +1100 (EST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09560-04 for ; Tue, 19 Feb 2013 10:43:55 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context Date: Tue, 19 Feb 2013 10:42:53 -0000 Message-ID: In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com> References: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com> <20130218123920.26245.56709.stgit@srivatsabhat.in.ibm.com> <51225A36.40600@linux.vnet.ibm.com> <51227810.6090009@linux.vnet.ibm.com> <51234C23.2030909@linux.vnet.ibm.com> From: "David Laight" To: "Srivatsa S. Bhat" , "Michel Lespinasse" Cc: linux-doc@vger.kernel.org, peterz@infradead.org, fweisbec@gmail.com, linux-kernel@vger.kernel.org, mingo@kernel.org, linux-arch@vger.kernel.org, linux@arm.linux.org.uk, 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, rjw@sisk.pl, namhyung@kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, oleg@redhat.com, vincent.guittot@linaro.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: , > I wouldn't go that far... ;-) Unfairness is not a show-stopper right? > IMHO, the warning/documentation should suffice for anybody wanting to > try out this locking scheme for other use-cases. I presume that by 'fairness' you mean 'write preference'? I'd not sure how difficult it would be, but maybe have two functions for acquiring the lock for read, one blocks if there is a writer waiting, the other doesn't. That way you can change the individual call sites separately. The other place I can imagine a per-cpu rwlock being used is to allow a driver to disable 'sleep' or software controlled hardware removal while it performs a sequence of operations. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David.Laight@ACULAB.COM (David Laight) Date: Tue, 19 Feb 2013 10:42:53 -0000 Subject: [PATCH v6 08/46] CPU hotplug: Provide APIs to prevent CPU offline from atomic context In-Reply-To: <51234C23.2030909@linux.vnet.ibm.com> References: <20130218123714.26245.61816.stgit@srivatsabhat.in.ibm.com> <20130218123920.26245.56709.stgit@srivatsabhat.in.ibm.com> <51225A36.40600@linux.vnet.ibm.com> <51227810.6090009@linux.vnet.ibm.com> <51234C23.2030909@linux.vnet.ibm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > I wouldn't go that far... ;-) Unfairness is not a show-stopper right? > IMHO, the warning/documentation should suffice for anybody wanting to > try out this locking scheme for other use-cases. I presume that by 'fairness' you mean 'write preference'? I'd not sure how difficult it would be, but maybe have two functions for acquiring the lock for read, one blocks if there is a writer waiting, the other doesn't. That way you can change the individual call sites separately. The other place I can imagine a per-cpu rwlock being used is to allow a driver to disable 'sleep' or software controlled hardware removal while it performs a sequence of operations. David