From: Peter Williams <pwil3058@bigpond.net.au>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Kyle Moffett <mrmacman_g4@mac.com>, 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, 23 Dec 2005 14:06:32 +1100 [thread overview]
Message-ID: <43AB69B8.4080707@bigpond.net.au> (raw)
In-Reply-To: <1135297525.3685.57.camel@lade.trondhjem.org>
Trond Myklebust wrote:
> On Thu, 2005-12-22 at 19:02 -0500, Kyle Moffett wrote:
>
>>On Dec 22, 2005, at 17:59, Trond Myklebust wrote:
>>
>>>On Fri, 2005-12-23 at 09:33 +1100, Peter Williams wrote:
>>>
>>>>>It still has sod all business being in the NFS code. We don't
>>>>>touch task scheduling in the filesystem code.
>>>>
>>>>How do you explain the use of the TASK_INTERRUPTIBLE flag then?
>>>
>>>Oh, please...
>>>
>>>TASK_INTERRUPTIBLE is used to set the task to sleep. It has NOTHING
>>>to do with scheduling.
>>
>>Putting a task to sleep _is_ rescheduling it. TASK_NONINTERACTIVE
>>means that you are about to reschedule and are willing to tolerate a
>>higher wakeup latency. TASK_INTERRUPTABLE means you are about to
>>sleep and want to be woken up using the "standard" latency. If you
>>do any kind of sleep at all, both are valid, independent of what part
>>of the kernel you are. There's a reason that both are TASK_* flags.
>
>
> Tolerance for higher wakeup latencies is a scheduling _policy_ decision.
> Please explain why the hell we should have to deal with that in
> filesystem code?
In order to make good decisions it needs good data. I don't think that
it's unreasonable to expect sub systems to help in that regard
especially when there is no cost involved. The patch just turns another
bit on (at compile time) in some integer constants. No extra space or
computing resources are required.
>
> As far as a filesystem is concerned, there should be 2 scheduling
> states: running and sleeping. Any scheduling policy beyond that belongs
> in kernel/*.
Actually there are currently two kinds of sleep: interruptible and
uninterruptible. This just adds a variation to one of these,
interruptible, that says even though I'm interruptible I'm not
interactive (i.e. I'm not waiting for human intervention via a key
press, mouse action, etc. to initiate the interrupt). This helps the
scheduler to decide whether the task involved is an interactive one or
not which in turn improves users' interactive experiences by ensuring
snappy responses to keyboard and mouse actions even when the system is
heavily loaded.
There are probably many interruptible sleeps in the kernel that should
be marked as non interactive but for most of them it doesn't matter
because the duration of the sleep is so short that being mislabelled
doesn't materially effect the decision re whether a task is interactive
or not. However, for reasons not related to the quality or efficiency
of the code, NFS interruptible sleeps do not fall into that category as
they can be quite long due to server load or network congestion. (N.B.
the size of delays that can be significant is quite small i.e. much less
than the size of a normal time slice.)
An alternative to using TASK_NONINTERACTIVE to mark non interactive
interruptible sleeps that are significant (probably a small number)
would be to go in the other direction and treat all interruptible sleeps
as being non interactive and then labelling all the ones that are
interactive as such. Although this would result in no changes being
made to the NFS code, I'm pretty sure that this option would involve a
great deal more code changes elsewhere as all the places where genuine
interactive sleeping were identified and labelled.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2005-12-23 3:30 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 [this message]
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
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=43AB69B8.4080707@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mrmacman_g4@mac.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).