From: Peter Williams <pwil3058@bigpond.net.au>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: 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: Wed, 21 Dec 2005 17:32:52 +1100 [thread overview]
Message-ID: <43A8F714.4020406@bigpond.net.au> (raw)
In-Reply-To: <1135145341.7910.17.camel@lade.trondhjem.org>
Trond Myklebust wrote:
> On Wed, 2005-12-21 at 17:00 +1100, Peter Williams wrote:
>
>>This patch addresses the adverse effect that the NFS client can have on
>>interactive response when CPU bound tasks (such as a kernel build)
>>operate on files mounted via NFS. (NB It is emphasized that this has
>>nothing to do with the effects of interactive tasks accessing NFS
>>mounted files themselves.)
>>
>>The problem occurs because tasks accessing NFS mounted files for data
>>can undergo quite a lot of TASK_INTERRUPTIBLE sleep depending on the
>>load on the server and the quality of the network connection. This can
>>result in these tasks getting quite high values for sleep_avg and
>>consequently a large priority bonus. On the system where I noticed this
>>problem they were getting the full 10 bonus points and being given the
>>same dynamic priority as genuine interactive tasks such as the X server
>>and rythmbox.
>>
>>The solution to this problem is to use TASK_NONINTERACTIVE to tell the
>>scheduler that the TASK_INTERRUPTIBLE sleeps in the NFS client and
>>SUNRPC are NOT interactive sleeps.
>
>
> Sorry. That theory is just plain wrong. ALL of those case _ARE_
> interactive sleeps.
It's not a theory. It's a result of observing a -j 16 build with the
sources on an NFS mounted file system with top with and without the
patches and comparing that with the same builds with the sources on a
local file system. Without the patches the tasks in the kernel build
all get the same dynamic priority as the X server and other interactive
programs when the sources are on an NFS mounted file system. With the
patches they generally have dynamic priorities between 6 to 10 higher
than the X server and other interactive programs.
In both cases, when the build is run on a source on a local file system
the kernel build tasks all have dynamic priorities 6 to 10 higher than
the X server and other interactive programs.
In all cases, the dynamic priorities of the X server and other
interactive programs are the same.
In the testing that I have done so far the patch has not resulted in any
genuine interactive tasks not being identified as interactive.
Peter
PS There's a difference between interruptible and interactive in that
while all interactive sleeps will be interruptible not all interruptible
sleeps are interactive. Ingo introduced TASK_NONINTERACTIVE to enable
this distinction to be made.
--
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-21 6:32 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 [this message]
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
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=43A8F714.4020406@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--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.