From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753205AbXDUQyj (ORCPT ); Sat, 21 Apr 2007 12:54:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753258AbXDUQyj (ORCPT ); Sat, 21 Apr 2007 12:54:39 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:55636 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753205AbXDUQyi (ORCPT ); Sat, 21 Apr 2007 12:54:38 -0400 Date: Sat, 21 Apr 2007 18:53:47 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Willy Tarreau , 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: <20070421165347.GA26903@elte.hu> 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.4.2.2i X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.1.7 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * 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". yeah. One problem i can see with the implementation of this though is that shells typically do nonspecific waits - for example bash does this on a simple 'ls' command: 21310 clone(child_stack=0, ...) = 21399 ... 21399 execve("/bin/ls", ... 21310 waitpid(-1, the PID is -1 so we dont actually know which task we are waiting for. We could use the first entry from the p->children list, but that looks too specific of a hack to me. It should catch most of the synchronous-helper-task cases though. Ingo