public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org,
	mingo@elte.hu, "Andrew Morton" <akpm@osdl.org>,
	"Mike Galbraith" <efault@gmx.de>
Subject: Re: Regression seen for patch "sched:dont decrease idle sleep avg"
Date: Thu, 18 May 2006 11:38:25 +1000	[thread overview]
Message-ID: <200605181138.26399.kernel@kolivas.org> (raw)
In-Reply-To: <4t16i2$142pji@orsmga001.jf.intel.com>

On Thursday 18 May 2006 11:10, Chen, Kenneth W wrote:
> Con Kolivas wrote on Wednesday, May 17, 2006 5:35 PM
>
> > What is missing
> > from the comment is to say that it is also designed to stop them at the
> > lowest possible priority that still keeps them in the interactive
> > reinsertion class.
> >
> > Using a constant ceiling value irrespective of nice will not guarantee
> > that tasks fall into the active reinsertion class dependant on their nice
> > value.
>
> If I may ask, how does it work right now?  Ceiling is set at constant value
> irrespective to nice value.  Are you saying current code is broken as well?

In essence, yes. The approximation was too general and vague as you have 
pointed out, and was only close to the correct ceiling or knee for one nice 
value.  I just want to formalise the relationship between the ceiling, nice 
value and INTERACTIVE_SLEEP and make the comment clear enough to be 
understood.

>         ceiling = JIFFIES_TO_NS(MAX_SLEEP_AVG -
>                   DEF_TIMESLICE);
>         if (p->sleep_avg < ceiling)
>                   p->sleep_avg = ceiling;
>
>
> We maybe also misunderstand each other.  I'm not arguing of removing the
> ceiling. Having a ceiling is the right thing to do here.  What I don't like
> is that 2.6.17-rc4 has the ceiling set too high, and your patch also does
> an inversion of the ceiling value w.r.t nice value.  So it's the detail of
> what's the right value for priority boost that I'm uncomfortable with.

We're in fuzzy land where there are no absolutes I'm afraid. The common case 
is obviously nice 0 and anything else is simply respecting the relationship 
between nice and INTERACTIVE_SLEEP. As timeslices get proportionately larger 
the lower the nice value, it becomes increasingly easy to avoid getting to 
the end of a full timeslice thereby avoiding expiration anyway. It also 
doesn't take much sleep from a task to get to best priority from the priority 
knee/ceiling no matter how low it is. Finally the relationship between likely 
preemption with varying nice levels is sort of vaguely maintained. On balance 
it seems satisfactory to me to maintain this relationship.

-- 
-ck

  reply	other threads:[~2006-05-18  1:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-08 23:18 Regression seen for patch "sched:dont decrease idle sleep avg" Tim Chen
2006-05-09  0:43 ` Con Kolivas
2006-05-09  1:07   ` Martin Bligh
2006-05-12  0:04   ` Chen, Kenneth W
2006-05-13 12:27     ` Andrew Morton
2006-05-13 13:07       ` Mike Galbraith
2006-05-14 16:03     ` Con Kolivas
2006-05-15 19:01       ` Chen, Kenneth W
2006-05-15 23:45         ` Con Kolivas
2006-05-16  1:22           ` Chen, Kenneth W
2006-05-16  1:44             ` Con Kolivas
2006-05-16  4:10           ` Mike Galbraith
2006-05-16 23:32           ` Tim Chen
2006-05-17  4:25             ` Mike Galbraith
2006-05-17  4:45               ` Peter Williams
2006-05-17  5:24                 ` Mike Galbraith
2006-05-17  8:23             ` Con Kolivas
2006-05-17  9:49               ` Mike Galbraith
2006-05-17 10:25                 ` Con Kolivas
2006-05-17 11:42                   ` Mike Galbraith
2006-05-17 12:46                     ` Con Kolivas
2006-05-17 13:41                       ` Mike Galbraith
2006-05-17 15:10                         ` Con Kolivas
2006-05-17 17:21                           ` Ray Lee
2006-05-17 19:33               ` Chen, Kenneth W
2006-05-18  0:35                 ` Con Kolivas
2006-05-18  1:10                   ` Chen, Kenneth W
2006-05-18  1:38                     ` Con Kolivas [this message]
2006-05-18  5:44                       ` Mike Galbraith
2006-05-18  5:52                         ` Con Kolivas
2006-05-18  7:04                           ` Mike Galbraith
2006-05-18 12:59                             ` Mike Galbraith
2006-05-19  1:10                               ` Con Kolivas
2006-05-18 23:17                           ` Chen, Kenneth W
2006-05-19  1:30                             ` [PATCH] sched: fix interactive ceiling code Con Kolivas
2006-05-19  2:02                               ` Mike Galbraith
2006-05-19  9:40                               ` Ingo Molnar
2006-05-19 14:37                               ` Chen, Kenneth W
2006-05-19 16:19                                 ` tim_c_chen
2006-05-18 23:34                           ` Regression seen for patch "sched:dont decrease idle sleep avg" Chen, Kenneth W
2006-05-19  1:07                             ` Con Kolivas
2006-05-16  4:07         ` Mike Galbraith
  -- strict thread matches above, loose matches on Subject: below --
2006-05-18  4:01 Al Boldi

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=200605181138.26399.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tim.c.chen@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox