All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.