All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ken Moffat <zarniwhoop@ntlworld.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	lkml <linux-kernel@vger.kernel.org>,
	a.p.zijlstra@chello.nl, aneesh.kumar@linux.vnet.ibm.com,
	dhaval@linux.vnet.ibm.com, Balbir Singh <balbir@in.ibm.com>,
	skumar@linux.vnet.ibm.com
Subject: Re: Regression in gdm-2.18 since 2.6.24
Date: Sat, 5 Apr 2008 22:03:47 +0100	[thread overview]
Message-ID: <20080405210347.GA19097@deepthought> (raw)
In-Reply-To: <20080405144042.GB24075@linux.vnet.ibm.com>

On Sat, Apr 05, 2008 at 08:10:43PM +0530, Srivatsa Vaddagiri wrote:
> 
> Given that you seem to be seeing the problem even without
> CONFIG_GROUP_SCHED, only the second hunk of the patch seems to be making
> a difference for your problem i.e just the hunk below applied on
> 2.6.25-rc8 (to kernel/sched_fair.c) should fix your problem too:
> 
> @@ -1145,7 +1145,7 @@ static void check_preempt_wakeup(struct 
>  	 * More easily preempt - nice tasks, while not making
>  	 * it harder for + nice tasks.
>  	 */
> -	if (unlikely(se->load.weight > NICE_0_LOAD))
> +	if (unlikely(se->load.weight != NICE_0_LOAD))
>  		gran = calc_delta_fair(gran, &se->load);
>  
>  	if (pse->vruntime + gran < se->vruntime)
> 
> [The first hunk is a no-op under !CONFIG_GROUP_SCHED, since
> entity_is_task() is always 1 for !CONFIG_GROUP_SCHED]
> 
> This second hunk changes how fast + or - niced tasks get preempted. 
> 
> 2.6.25-rc8 (Bad case):
> 	Sets preempt granularity for + niced tasks at 5ms (1 CPU)
> 
> 2.6.25-rc8 + the hunk above (Good case):
> 	Sets preempt granularity for + niced tasks at >5ms
> 
 Well, I'm no longer sure exactly what was in the config, but after
I had confirmed the reversion would fix 2.6.24.4 I _did_ try just
the second part of the patch applied to 2.6.25-rc8 and it gave a 60%
success rate across 10 tests.
> 
> So bumping up preempt granularity for + niced tasks seems to make things
> work for you. IMO the deeper problem lies somewhere else (perhaps is
> some race issue in gdm itself), which is easily exposed with 2.6.25-rc8 
> which lets + niced tasks be preempted quickly.
> 

 I agree this is probably exposing a problem somewhere else.

> To help validate this, can you let us know the result of tuning preempt
> granularity on native 2.6.25-rc8 (without any patches applied and
> CONFIG_GROUP_SCHED disabled)?
> 
> 	# echo 100000000 > /proc/sys/kernel/sched_wakeup_granularity_ns
> 
> To check if echo command worked, do:
> 
> 	# cat /proc/sys/kernel/sched_wakeup_granularity_ns
> 
> It should return 100000000.
> 
> Now try shutting down thr' gdm and pls let me know if it makes a
> difference.
> 
> -- 
> Regards,
> vatsa

 Will do, but it might be a day or so before I can get to this.

Thanks.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

  reply	other threads:[~2008-04-05 21:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-03 19:19 Regression in gdm-2.18 since 2.6.24 Ken Moffat
2008-04-03 19:56 ` Rafael J. Wysocki
2008-04-03 21:08   ` Ken Moffat
2008-04-03 21:29     ` Rafael J. Wysocki
2008-04-03 23:48       ` Ken Moffat
2008-04-04  0:20         ` Rafael J. Wysocki
2008-04-04 12:37           ` Ken Moffat
2008-04-04 14:48             ` Dhaval Giani
2008-04-04 15:02               ` Ken Moffat
2008-04-04 14:47         ` Dhaval Giani
2008-04-04 15:00           ` Ken Moffat
2008-04-04 14:37 ` Srivatsa Vaddagiri
2008-04-04 15:32   ` Ken Moffat
2008-04-05 14:40     ` Srivatsa Vaddagiri
2008-04-05 21:03       ` Ken Moffat [this message]
2008-04-06 23:48         ` Ken Moffat
2008-04-08  8:50           ` Srivatsa Vaddagiri
2008-04-08  8:42             ` Peter Zijlstra
2008-04-08 11:21             ` Carlos R. Mafra
2008-04-09 13:07             ` Ken Moffat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080405210347.GA19097@deepthought \
    --to=zarniwhoop@ntlworld.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=balbir@in.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=skumar@linux.vnet.ibm.com \
    --cc=vatsa@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.