From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935633AbZLGWYQ (ORCPT ); Mon, 7 Dec 2009 17:24:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934457AbZLGWYO (ORCPT ); Mon, 7 Dec 2009 17:24:14 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:54739 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934388AbZLGWYN (ORCPT ); Mon, 7 Dec 2009 17:24:13 -0500 To: paulmck@linux.vnet.ibm.com Cc: Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Christoph Hellwig , Nick Piggin , Linux Kernel Mailing List , Oleg Nesterov References: <20091130100041.GA29610@infradead.org> <20091130174638.GA9782@elte.hu> <1259616429.26472.499.camel@laptop> <20091207181816.GF6808@linux.vnet.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Mon, 07 Dec 2009 14:24:13 -0800 In-Reply-To: <20091207181816.GF6808@linux.vnet.ibm.com> (Paul E. McKenney's message of "Mon\, 7 Dec 2009 10\:18\:16 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=76.21.114.89;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 76.21.114.89 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [rfc] "fair" rw spinlocks X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: No (on in01.mta.xmission.com); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Paul E. McKenney" writes: > > Is it required that all of the processes see the signal before the > corresponding interrupt handler returns? (My guess is "no", which > enables a trick or two, but thought I should ask.) Not that I recall. I think it is just an I/O completed signal. >> The trouble as I recall is how to ensure new processes see the signal. > > And can we afford to serialize signals to groups of processes? Not > necessarily one at a time, but a limited set at a given time? > Alternatively, a long list of pending group signals for each new task to > walk? Semantically I don't believe there are not any particular ordering requirements, except that the work must be done before we return from the kernel. In the ideal implementation we could have hundreds of processes sending signals to the same process group without affecting the rest of the kernel. The current implementation is a concern for scaling and we have been removing it where we can. Eric