From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030918AbXDQXA4 (ORCPT ); Tue, 17 Apr 2007 19:00:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030921AbXDQXA4 (ORCPT ); Tue, 17 Apr 2007 19:00:56 -0400 Received: from qb-out-0506.google.com ([72.14.204.235]:43873 "EHLO qb-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030918AbXDQXAz (ORCPT ); Tue, 17 Apr 2007 19:00:55 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lPXOZ2FVh4BXQkw3WqzCPqDVLC5PbCnGoH4hZpSaGYPsluXRqej0L5VFwwFEb70DDeXCz0bUciwNxASZtSGZ5mT42s48nWB6lm8R7SX5lpkkUPWSzBX9D2vG5HdG93J1H0IGA5J9E5vvBrwznsztCEJ2wOPEfgsYuSaFvc4W1YE= Message-ID: Date: Tue, 17 Apr 2007 16:00:53 -0700 From: "Michael K. Edwards" To: "Peter Williams" Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] Cc: "Ingo Molnar" , "Nick Piggin" , "Mike Galbraith" , "Con Kolivas" , "ck list" , "Bill Huey" , linux-kernel@vger.kernel.org, "Linus Torvalds" , "Andrew Morton" , "Arjan van de Ven" , "Thomas Gleixner" In-Reply-To: <4624CF3B.6040704@bigpond.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070413202100.GA9957@elte.hu> <200704151327.13589.kernel@kolivas.org> <1176619384.6222.70.camel@Homer.simpson.net> <46240F98.3020800@bigpond.net.au> <1176776941.6222.21.camel@Homer.simpson.net> <20070417034050.GD25513@wotan.suse.de> <1176782489.13059.15.camel@Homer.simpson.net> <20070417041420.GF25513@wotan.suse.de> <20070417095140.GB22626@elte.hu> <4624CF3B.6040704@bigpond.net.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 4/17/07, Peter Williams wrote: > The other way in which the code deviates from the original as that (for > a few years now) I no longer calculated CPU bandwidth usage directly. > I've found that the overhead is less if I keep a running average of the > size of a tasks CPU bursts and the length of its scheduling cycle (i.e. > from on CPU one time to on CPU next time) and using the ratio of these > values as a measure of bandwidth usage. > > Anyway it works and gives very predictable allocations of CPU bandwidth > based on nice. Works, that is, right up until you add nonlinear interactions with CPU speed scaling. From my perspective as an embedded platform integrator, clock/voltage scaling is the elephant in the scheduler's living room. Patch in DPM (now OpPoint?) to scale the clock based on what task is being scheduled, and suddenly the dynamic priority calculations go wild. Nip this in the bud by putting an RT priority on the relevant threads (which you have to do anyway if you need remotely audio-grade latency), and the lock affinity heuristics break, so you have to hand-tune all the thread priorities. Blecch. Not to mention the likelihood that the task whose clock speed you're trying to crank up (say, a WiFi soft MAC) needs to be _lower_ priority than the application. (You want to crank the CPU for this task because it runs with the RF hot, which may cost you as much power as the rest of the platform.) You'd better hope you can remove it from the dynamic priority heuristics with SCHED_BATCH. Otherwise everything _else_ has to be RT priority (or it'll be starved by the soft MAC) and you've basically tossed SCHED_NORMAL in the bin. Double blecch! Is it too much to ask for someone with actual engineering training (not me, unfortunately) to sit down and build a negative-feedback control system that handles soft-real-time _and_ dynamic-priority _and_ batch loads, CPU _and_ I/O scheduling, preemption _and_ clock scaling? And actually separates the accounting and control mechanisms from the heuristics, so the latter can be tuned (within a well documented stable range) to reflect the expected system usage patterns? It's not like there isn't a vast literature in this area over the past decade, including some dealing specifically with clock scaling consistent with low-latency applications. It's a pity that people doing academic work in this area rarely wade into LKML, even when they're hacking on a Linux fork. But then, there's not much economic incentive for them to do so, and they can usually get their fill of citation politics and dominance games without leaving their home department. :-P Seriously, though. If you're really going to put the mainline scheduler through this kind of churn, please please pretty please knit in per-task clock scaling (possibly even rejigged during the slice; see e. g. Yuan and Nahrstedt's GRACE-OS papers) and some sort of linger mechanism to keep from taking context switch hits when you're confident that an I/O will complete quickly. Cheers, - Michael