Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150AbYJUL6W (ORCPT ); Tue, 21 Oct 2008 07:58:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753993AbYJUL6G (ORCPT ); Tue, 21 Oct 2008 07:58:06 -0400 Received: from mu-out-0910.google.com ([209.85.134.189]:61552 "EHLO mu-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753997AbYJUL6E (ORCPT ); Tue, 21 Oct 2008 07:58:04 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Cp0BxrgZbRFD4DkTCJJKQhYO3cfi+w5NpxpArCXP7bXdsiC5tGRfX0i4u4KhuPtsh4 GUoNRo7y+88OV+qyyNAFZK9tCgo6UFy8g7bZoVStLxdi4PPLiqXvl6wdeu0PU1pkqjJS iLBocL4jqz+FX+9qdhxNEba04VqKd6y/y7vsk= Message-ID: Date: Tue, 21 Oct 2008 13:58:02 +0200 From: "Zdenek Kabelac" To: "Chris Snook" Subject: Re: Scheduler on C2D CPU and latest 2.6.27 kernel Cc: "Linux Kernel Mailing List" , "Ingo Molnar" , "Peter Zijlstra" In-Reply-To: <48FDC03B.3050708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48FDB7E7.4090007@redhat.com> <48FDC03B.3050708@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2903 Lines: 98 2008/10/21 Chris Snook : > Zdenek Kabelac wrote: >> >> 2008/10/21 Chris Snook : >>> >>> Zdenek Kabelac wrote: >>>> >>>> Hi >>>> >>>> Recently I'm noticing bad behavior of the CPU scheduler on my T61 (2GB, >>>> C2D) >>>> >>>> It looks like Linux concentrates all running tasks on one CPU and the >>>> second cpu is sleeping. >>>> >>>> With recent changes to DRI - glxgears went up to 840FPS but also takes >>>> 100% (with Xorg) and when I run 'while :; do true; done' loop in >>>> parallel frame rate drops to 300FPS. >>>> >>>> But as I have C2D CPU I would expect that there should be no such >>>> dramatic slowdown. >>>> >>>> Xosview shows that only one CPU is fully loaded. >>>> >>>> Here are my .config scheduler options: >>>> >>>> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y >>>> # CONFIG_GROUP_SCHED is not set >>>> CONFIG_IOSCHED_NOOP=y >>>> CONFIG_IOSCHED_AS=y >>>> CONFIG_IOSCHED_DEADLINE=y >>>> CONFIG_IOSCHED_CFQ=y >>>> CONFIG_DEFAULT_IOSCHED="cfq" >>>> CONFIG_SCHED_SMT=y >>>> # CONFIG_SCHED_MC is not set >> >> I've also tested SMT=n MC=y - with same result > > Expected. > >>>> CONFIG_SCHED_HRTICK=y >>>> # CONFIG_NET_SCHED is not set >>>> CONFIG_USB_EHCI_TT_NEWSCHED=y >>>> CONFIG_SCHED_DEBUG=y >>>> CONFIG_SCHEDSTATS=y >>>> CONFIG_SCHED_TRACER=y >>>> >>>> >>>> Am I missing something? >>> >>> You're running a loop that does nothing except create new tasks that have >>> no >>> scheduling history, and then disappear before the scheduler can migrate >>> them. >>> >>> Try running 'openssl speed' to chew up CPU. I promise you the scheduler >>> will behave very nicely. >> >> Well - sorry you really shouldn't promise things you cannot guarantee. > > You must be new here. hmm, I don't think so :) > >> It's obviously showing exactly same problem on my box. > > If you start 2 'openssl speed' tasks while glxgears is running, what > happens? > >> And I should add that with 2.6.27-rc8 I do not experience this behavior. > > Thanks. Can you bisect? Maybe the author of this regression will 'confess' himself and will safe my time? I can see some major merge on Oct 20 for kernel/sched.c > >> Gears are showning 80% speed - but consumes only 25% >> and bash loop or openssl speed task do not influence its speed. >> (as expected with 2CPU machine) > > That's definitely what it should be doing with openssl speed. The bash loop > isn't something we should go out of our way to optimize for, since real > world apps don't behave that way, but if there's a free fix, we might as > well do it. You really should check first what the loop I've posted actually does :) (hint - /bin/true != true) Zdenek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/