From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753189AbXDUQqm (ORCPT ); Sat, 21 Apr 2007 12:46:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753199AbXDUQqm (ORCPT ); Sat, 21 Apr 2007 12:46:42 -0400 Received: from holomorphy.com ([66.93.40.71]:58563 "EHLO holomorphy.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753189AbXDUQql (ORCPT ); Sat, 21 Apr 2007 12:46:41 -0400 Date: Sat, 21 Apr 2007 09:42:41 -0700 From: William Lee Irwin III To: Linus Torvalds Cc: Willy Tarreau , 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: <20070421164241.GF2986@holomorphy.com> 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: Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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. On Sat, Apr 21, 2007 at 09:34:07AM -0700, Linus Torvalds wrote: > 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". An in-kernel scheduler API might help. void yield_to(struct task_struct *)? A userspace API might be nice, too. e.g. int sched_yield_to(pid_t). -- wli