public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE][RFC] PlugSched-5.2.1 for 2.6.11 and 2.6.12
Date: Tue, 5 Jul 2005 22:16:44 +1000	[thread overview]
Message-ID: <200507052216.45018.kernel@kolivas.org> (raw)
In-Reply-To: <42CA6E2F.7000408@bigpond.net.au>

On Tue, 5 Jul 2005 21:25, Peter Williams wrote:
> Con Kolivas wrote:
> > On Tue, 5 Jul 2005 17:46, Peter Williams wrote:
> >>Peter Williams wrote:
> >>>Con Kolivas wrote:
> >>>>On Mon, 20 Jun 2005 15:33, Peter Williams wrote:
> >>>>>PlugSched-5.2.1 is available for 2.6.11 and 2.6.12 kernels.  This
> >>>>>version applies Con Kolivas's latest modifications to his "nice" aware
> >>>>>SMP load balancing patches.
> >>>>
> >>>>Thanks Peter.
> >>>>Any word from your own testing/testers on how well smp nice balancing
> >>>>is working for them now?
> >>>
> >>>No, they got side tracked onto something else but should start working
> >>>on it again soon.  I'll give them a prod :-)
> >>
> >>Con,
> >>	We've done some more testing with this with results that are still
> >>disappointing.
> >
> > Is this with the migration thread accounted patch as well?

The results from smp nice I've received so far show that a 30% slowdown 
(instead of 5% on uniprocessor) occurs to high priority tasks in the presence 
of low priority tasks worst case scenario when the tasks sleep frequently. 
However excellent smp nice support with negligible slowdown occurs (ie nice 
is well respected) when the tasks are fully cpu bound. This suggests that 
what is happening on task wakeup is the limiting factor with this smp nice 
implementation. This makes sense given that most of the balancing occurs 
during busy rebalance when the queues are busy. I tried ignoring the length 
of queue (ie not having the single task running check for idle rebalance) and 
while this improved the nice effect substantially, it also cost us heavily in 
throughput making it unwarranted.

Cheers,
Con

      reply	other threads:[~2005-07-05 12:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-20  5:33 [ANNOUNCE][RFC] PlugSched-5.2.1 for 2.6.11 and 2.6.12 Peter Williams
2005-06-20  5:41 ` Con Kolivas
2005-06-20  6:18   ` Peter Williams
2005-07-05  7:46     ` Peter Williams
2005-07-05  9:53       ` Con Kolivas
2005-07-05 11:25         ` Peter Williams
2005-07-05 12:16           ` Con Kolivas [this message]

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=200507052216.45018.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pwil3058@bigpond.net.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox