From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031229AbXDUOKP (ORCPT ); Sat, 21 Apr 2007 10:10:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1031235AbXDUOKO (ORCPT ); Sat, 21 Apr 2007 10:10:14 -0400 Received: from mail.tmr.com ([64.65.253.246]:44271 "EHLO gaimboi.tmr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031229AbXDUOKM (ORCPT ); Sat, 21 Apr 2007 10:10:12 -0400 Message-ID: <462A1B12.8090001@tmr.com> Date: Sat, 21 Apr 2007 10:09:22 -0400 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061105 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Ingo Molnar CC: Davide Libenzi , Linus Torvalds , Matt Mackall , Nick Piggin , William Lee Irwin III , Peter Williams , Mike Galbraith , Con Kolivas , ck list , Bill Huey , Linux Kernel Mailing List , Andrew Morton , Arjan van de Ven , Thomas Gleixner Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] References: <20070418055525.GS11115@waste.org> <20070418152355.GU11115@waste.org> <20070418174945.GA7930@elte.hu> <20070418175936.GA11980@elte.hu> <20070418214816.GA10902@elte.hu> <20070419080053.GA4106@elte.hu> In-Reply-To: <20070419080053.GA4106@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar wrote: > * Davide Libenzi wrote: >> The same user nicing two different multi-threaded processes would >> expect a predictable CPU distribution too. [...] > > i disagree that the user 'would expect' this. Some users might. Others > would say: 'my 10-thread rendering engine is more important than a > 1-thread job because it's using 10 threads for a reason'. And the CFS > feedback so far strengthens this point: the default behavior of treating > the thread as a single scheduling (and CPU time accounting) unit works > pretty well on the desktop. > If by desktop you mean "one and only one interactive user," that's true. On a shared machine it's very hard to preserve any semblance of fairness when one user gets far more than another, based not on the value of what they're doing but the tools they use to to it. > think about it in another, 'kernel policy' way as well: we'd like to > _encourage_ more parallel user applications. Hurting them by accounting > all threads together sends the exact opposite message. > Why is that? There are lots of things which are intrinsically single threaded, how are we hurting hurting multi-threaded applications by refusing to give them more CPU than an application running on behalf of another user? By accounting all threads together we encourage writing an application in the most logical way. Threads are a solution, not a goal in themselves. >> [...] Doing that efficently (the old per-cpu run-queue is pretty nice >> from many POVs) is the real challenge. > > yeah. > > Ingo -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot