From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753376AbXDUQzU (ORCPT ); Sat, 21 Apr 2007 12:55:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753309AbXDUQzU (ORCPT ); Sat, 21 Apr 2007 12:55:20 -0400 Received: from 1wt.eu ([62.212.114.60]:2126 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753376AbXDUQzS (ORCPT ); Sat, 21 Apr 2007 12:55:18 -0400 Date: Sat, 21 Apr 2007 18:53:26 +0200 From: Willy Tarreau To: Linus Torvalds Cc: Ingo Molnar , Con Kolivas , linux-kernel@vger.kernel.org, Andrew Morton , Nick Piggin , Mike Galbraith , Arjan van de Ven , Peter Williams , Thomas Gleixner , caglar@pardus.org.tr, Gene Heskett Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Message-ID: <20070421165326.GD7840@1wt.eu> References: <20070420140457.GA14017@elte.hu> <20070421121235.GA2044@1wt.eu> <20070421154614.GA26169@elte.hu> <20070421161818.GC7840@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 21, 2007 at 09:34:07AM -0700, Linus Torvalds wrote: > > > On Sat, 21 Apr 2007, Willy Tarreau wrote: > > > > If you remember, with 50/50, I noticed some difficulties to fork many > > processes. I think that during a fork(), the parent has a higher probability > > of forking other processes than the child. So at least, we should use > > something like 67/33 or 75/25 for parent/child. > > It would be even better to simply have the rule: > - child gets almost no points at startup > - but when a parent does a "waitpid()" call and blocks, it will spread > out its points to the childred (the "vfork()" blocking is another case > that is really the same). > > This is a very special kind of "priority inversion" logic: you give higher > priority to the things you wait for. Not because of holding any locks, but > simply because a blockign waitpid really is a damn big hint that "ok, the > child now works for the parent". I like this idea a lot. I don't know if it can be applied to pipes and unix sockets, but it's clearly a way of saying "hurry up, I'm waiting for you" which seems natural with inter-process communications. Also, if we can do this on unix sockets, it would help a lot with X ! Willy