From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761412AbXHALWy (ORCPT ); Wed, 1 Aug 2007 07:22:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757764AbXHALWq (ORCPT ); Wed, 1 Aug 2007 07:22:46 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:60737 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754045AbXHALWp (ORCPT ); Wed, 1 Aug 2007 07:22:45 -0400 Date: Wed, 1 Aug 2007 13:22:29 +0200 From: Ingo Molnar To: Roman Zippel Cc: Mike Galbraith , Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: CFS review Message-ID: <20070801112229.GA11710@elte.hu> References: <20070711174252.GA16793@elte.hu> <20070711211638.GE18767@one.firstfloor.org> <20070711214649.GK14435@v2.random> <1184302024.6709.11.camel@Homer.simpson.net> <1184389456.6632.13.camel@Homer.simpson.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.1.7-deb -1.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 * Roman Zippel wrote: > [...] e.g. in this example there are three tasks that run only for > about 1ms every 3ms, but they get far more time than should have > gotten fairly: > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l Mike and me have managed to reproduce similarly looking 'top' output, but it takes some effort: we had to deliberately run a non-TSC sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS. in that case 'top' accounting symptoms similar to the above are not due to the scheduler starvation you suspected, but due the effect of a low-resolution scheduler clock and a tightly coupled timer/scheduler tick to it. I tried the very same workload on 2.6.22 (with the same .config) and i saw similarly anomalous 'top' output. (Not only can one create really anomalous CPU usage, one can completely hide tasks from 'top' output.) if your test-box has a high-resolution sched_clock() [easily possible] then please send us the lt.c and l.c code so that we can have a look. Ingo