All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hawkes <hawkes@oss.sgi.com>
To: nickpiggin@yahoo.com.au, akpm@osdl.org,
	linux-kernel@vger.kernel.org, jbarnes@sgi.com
Cc: hawkes@sgi.com
Subject: [PATCH, 2.6.9] improved load_balance() tolerance for pinned tasks
Date: Wed, 20 Oct 2004 12:36:04 -0700	[thread overview]
Message-ID: <200410201936.i9KJa4FF026174@oss.sgi.com> (raw)

A large number of processes that are pinned to a single CPU results in
every other CPU's load_balance() seeing this overloaded CPU as "busiest",
yet move_tasks() never finds a task to pull-migrate.  This condition
occurs during module unload, but can also occur as a denial-of-service
using sys_sched_setaffinity().  Several hundred CPUs performing this
fruitless load_balance() will livelock on the busiest CPU's runqueue
lock.  A smaller number of CPUs will livelock if the pinned task count
gets high.  This simple patch remedies the more common first problem:
after a move_tasks() failure to migrate anything, the balance_interval
increments.  Using a simple increment, vs.  the more dramatic doubling of
the balance_interval, is conservative and yet also effective.

John Hawkes


Signed-off-by: John Hawkes <hawkes@sgi.com>




Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c	2004-10-19 15:04:11.000000000 -0700
+++ linux/kernel/sched.c	2004-10-19 15:09:50.000000000 -0700
@@ -2123,11 +2123,19 @@
 			 */
 			sd->nr_balance_failed = sd->cache_nice_tries;
 		}
-	} else
-		sd->nr_balance_failed = 0;
 
-	/* We were unbalanced, so reset the balancing interval */
-	sd->balance_interval = sd->min_interval;
+		/*
+		 * We were unbalanced, but unsuccessful in move_tasks(),
+		 * so bump the balance_interval to lessen the lock contention.
+		 */
+		if (sd->balance_interval < sd->max_interval)
+			sd->balance_interval++;
+	} else {
+                sd->nr_balance_failed = 0;
+
+		/* We were unbalanced, so reset the balancing interval */
+		sd->balance_interval = sd->min_interval;
+	}
 
 	return nr_moved;
 

             reply	other threads:[~2004-10-20 19:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-20 19:36 John Hawkes [this message]
2004-10-20 19:59 ` [PATCH, 2.6.9] improved load_balance() tolerance for pinned tasks Ingo Molnar
2004-10-22 13:08 ` Nick Piggin
2004-10-22 19:38 ` John Hawkes
     [not found]   ` <00ee01c4b870$030b80f0$6700a8c0@comcast.net>
2004-10-23  4:27     ` Nick Piggin
2004-10-25 16:02       ` John Hawkes
2004-10-25 23:59         ` Nick Piggin
2004-10-30  0:21         ` Matthew Dobson
  -- strict thread matches above, loose matches on Subject: below --
2004-10-22 19:20 John Hawkes
2004-10-23  4:22 ` Nick Piggin

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=200410201936.i9KJa4FF026174@oss.sgi.com \
    --to=hawkes@oss.sgi.com \
    --cc=akpm@osdl.org \
    --cc=hawkes@sgi.com \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.