All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Mike Galbraith <efault@gmx.de>
Cc: Helge Hafting <helgehaf@aitel.hist.no>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	Ingo Molnar <mingo@elte.hu>, Con Kolivas <kernel@kolivas.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Fix adverse effects of NFS client   on	interactive response
Date: Fri, 06 Jan 2006 10:13:16 +1100	[thread overview]
Message-ID: <43BDA80C.4020009@bigpond.net.au> (raw)
In-Reply-To: <5.2.1.1.2.20060105143705.00be85c8@pop.gmx.net>

Mike Galbraith wrote:
> At 10:31 PM 1/5/2006 +1100, Peter Williams wrote:
> 
>> Mike Galbraith wrote:
>>
>>> At 08:51 AM 1/5/2006 +1100, Peter Williams wrote:
>>>
>>>> I think that some of the harder to understand parts of the scheduler 
>>>> code are actually attempts to overcome the undesirable effects (such 
>>>> as those I've described) of inappropriately identifying tasks as 
>>>> interactive.  I think that it would have been better to attempt to 
>>>> fix the inappropriate identifications rather than their effects and 
>>>> I think the prudent use of TASK_NONINTERACTIVE is an important tool 
>>>> for achieving this.
>>>
>>>
>>> IMHO, that's nothing but a cover for the weaknesses induced by using 
>>> exclusively sleep time as an information source for the priority 
>>> calculation.  While this heuristic does work pretty darn well, it's 
>>> easily fooled (intentionally or otherwise).  The challenge is to find 
>>> the right low cost informational component, and to stir it in at O(1).
>>
>>
>> TASK_NONINTERACTIVE helps in this regard, is no cost in the code where 
>> it's used and probably decreases the costs in the scheduler code by 
>> enabling some processing to be skipped.  If by its judicious use the 
>> heuristic is only fed interactive sleep data the heuristics accuracy 
>> in identifying interactive tasks should be improved.  It may also 
>> allow the heuristic to be simplified.
> 
> 
> I disagree.  You can nip and tuck all the bits of sleep time you want, 
> and it'll just shift the lumpy spots around (btdt).

Yes, but there's a lot of (understandable) reluctance to do any major 
rework of this part of the scheduler so we're stuck with nips and tucks 
for the time being.  This patch is a zero cost nip and tuck.

If the plugsched patches were included in -mm we could get wider testing 
of alternative scheduling mechanisms.  But I think it will take a lot of 
testing of the new schedulers to allay fears that they may introduce new 
problems of their own.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-01-05 23:13 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21  6:00 [PATCH] sched: Fix adverse effects of NFS client on interactive response Peter Williams
2005-12-21  6:09 ` Trond Myklebust
2005-12-21  6:32   ` Peter Williams
2005-12-21 13:21     ` Trond Myklebust
2005-12-21 13:36       ` Kyle Moffett
2005-12-21 13:40         ` Trond Myklebust
2005-12-22  2:26           ` Peter Williams
2005-12-22 22:08             ` Trond Myklebust
2005-12-22 22:33               ` Peter Williams
2005-12-22 22:59                 ` Trond Myklebust
2005-12-23  0:02                   ` Kyle Moffett
2005-12-23  0:25                     ` Trond Myklebust
2005-12-23  3:06                       ` Peter Williams
2005-12-23  9:39                         ` Trond Myklebust
2005-12-23 10:49                           ` Peter Williams
2005-12-23 12:51                             ` Trond Myklebust
2005-12-23 13:36                               ` Peter Williams
2006-01-02 12:09                                 ` Pekka Enberg
2005-12-23 19:07                           ` Lee Revell
2005-12-23 21:08                             ` Trond Myklebust
2005-12-23 21:17                               ` Lee Revell
2005-12-23 21:23                                 ` Trond Myklebust
2005-12-23 22:04                                   ` Lee Revell
2005-12-23 22:10                                     ` Trond Myklebust
2005-12-21 16:10         ` Horst von Brand
2005-12-21 20:36           ` Kyle Moffett
2005-12-21 22:59             ` Peter Williams
2005-12-21 16:11     ` Ingo Molnar
2005-12-21 22:49       ` Peter Williams
2006-01-02 11:01     ` Helge Hafting
2006-01-02 23:54       ` Peter Williams
2006-01-04  1:25         ` Peter Williams
2006-01-04  9:40           ` Marcelo Tosatti
2006-01-04 12:18             ` Con Kolivas
2006-01-04 10:31               ` Marcelo Tosatti
2006-01-04 21:51           ` Peter Williams
2006-01-05  6:31             ` Mike Galbraith
2006-01-05 11:31               ` Peter Williams
2006-01-05 14:31                 ` Mike Galbraith
2006-01-05 23:13                   ` Peter Williams [this message]
2006-01-05 23:33                     ` Con Kolivas
2006-01-06  0:02                       ` Peter Williams
2006-01-06  0:08                         ` Con Kolivas
2006-01-06  0:40                           ` Peter Williams
2006-01-06  7:39                     ` Mike Galbraith
2006-01-07  1:11                       ` Peter Williams
2006-01-07  5:27                         ` Mike Galbraith
2006-01-07  6:34                           ` Peter Williams
2006-01-07  8:54                             ` Mike Galbraith
2006-01-07 23:40                               ` Peter Williams
2006-01-08  5:51                                 ` Mike Galbraith
2006-01-07  9:30                           ` Con Kolivas
2006-01-07 10:23                             ` Mike Galbraith
2006-01-07 23:31                             ` Peter Williams
2006-01-08  0:38                               ` Con Kolivas

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=43BDA80C.4020009@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=efault@gmx.de \
    --cc=helgehaf@aitel.hist.no \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=trond.myklebust@fys.uio.no \
    /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.