From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933612AbZLJKb4 (ORCPT ); Thu, 10 Dec 2009 05:31:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933594AbZLJKb4 (ORCPT ); Thu, 10 Dec 2009 05:31:56 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:54864 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933589AbZLJKbz (ORCPT ); Thu, 10 Dec 2009 05:31:55 -0500 To: paulmck@linux.vnet.ibm.com Cc: Oleg Nesterov , Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Christoph Hellwig , Nick Piggin , Linux Kernel Mailing List References: <1259616429.26472.499.camel@laptop> <20091207183226.GA20139@redhat.com> <20091209153709.GA13192@redhat.com> <20091210062220.GC6720@linux.vnet.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 10 Dec 2009 02:31:39 -0800 In-Reply-To: <20091210062220.GC6720@linux.vnet.ibm.com> (Paul E. McKenney's message of "Wed\, 9 Dec 2009 22\:22\:20 -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: > My main concern would be "fork storms", where each CPU in a large > system is spawning children in a pgrp that some other CPU is attempting > to kill. The CPUs spawning children might be able to keep ahead of > the single CPU, so that the pgrp never is completely killed. > > Enlisting the aid of the CPUs doing the spawning (e.g., by having them > consult a list of signals being sent) prevents this fork-storm scenario. We almost have a worst case bound. We can have at most max_thread processes. Unfortunately it appears we don't force an rcu grace period anywhere. So It does appear theoretically possible to fork and exit on a bunch of other cpus infinitely extending the rcu interval. Still that is all inside the tasklist_lock, which serializes all of those other cpus. So as long as the cost of queuing signals is less than the cost of adding processes to the task lists we won't have a problem. Eric