Date: Mon, 28 Jan 2008 13:27:52 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Cc: Guillaume Chazarain <guichaz@yahoo.fr>,
       LKML <linux-kernel@vger.kernel.org>, a.p.zijlstra@chello.nl,
       dhaval@linux.vnet.ibm.com
Subject: Re: High wake up latencies with FAIR_USER_SCHED
Message-ID: <20080128122752.GB24757@elte.hu>
References: <3d8471ca0801271201o5a41955cg552ef06a2f821285@mail.gmail.com> <20080128023129.GD1044@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080128023129.GD1044@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1173
Lines: 26


* Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote:

> NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and 
> not group-level entities. With the patch attached, I could see that 
> wakeup latencies with FAIR_USER_SCHED are restored to the same level 
> as !FAIR_USER_SCHED.
> 
> However I am not sure whether that is the way to go. We want to let 
> one group of tasks running as much as possible until the 
> fairness/wakeup-latency threshold is exceeded. If someone does want 
> better wakeup latencies between groups too, they can always tune 
> sysctl_sched_wakeup_granularity.

the patch does look like the right thing to do. There's nothing special 
about 'groups' versus 'tasks' in terms of scheduling. And most 
importantly, this solves the behavioral assymetry observed by Guillaume 
as well - which makes it an obvious-to-add regression fix. I've added 
your patch to the scheduler queue.

	Ingo
--
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/