Date: Sun, 31 Aug 2003 13:20:58 -0700
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Nick Piggin <piggin@cyberone.com.au>,
       linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Nick's scheduler policy v10
Message-ID: <1806700000.1062361257@[10.10.2.4]>
In-Reply-To: <3F5044DC.10305@cyberone.com.au>
References: <3F5044DC.10305@cyberone.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2473
Lines: 54

> This is quite a big change from v8. Fixes a few bugs in child priority,
> and adds a small lower bound on the amount of history that is kept. This
> should improve "fork something" times hopefully, and stops new children
> being able to fluctuate priority so wildly.
> 
> Eliminates "timeslice backboost" and only uses "priority backboost". This
> decreases scheduling latency quite nicely - I can only measure 130ms for
> a very low priority task, with a make -j3 and wildly moving an xterm around
> in front of a mozilla window.
> 
> Makes a fairly fundamental change to how sleeping/running is accounted.
> It now takes into account time on the runqueue. This hopefully will keep
> priorities more stable under varying loads.
> 
> Includes an upper bound on the amount of priority a task can get in one
> sleep. Hopefully this catches freak long sleeps like a SIGSTOP or unexpected
> swaps. This change breaks the priority calculation a little bit. I'm thinking
> about how to fix it.
> 
> Feedback welcome! Its against 0-test4, as usual.

Oooh - much better.

Kernbench: (make -j vmlinux, maximal tasks)
                              Elapsed      System        User         CPU
              2.6.0-test4       45.87      116.92      571.10     1499.00
         2.6.0-test4-nick       49.37      131.31      611.15     1500.75
       2.6.0-test4-nick7a       49.48      125.95      617.71     1502.00
       2.6.0-test4-nick10       46.91      114.03      584.16     1489.25

SDET 128  (see disclaimer)
                           Throughput    Std. Dev
              2.6.0-test4       100.0%         0.3%
         2.6.0-test4-nick       102.9%         0.3%
       2.6.0-test4-nick7a       105.1%         0.5%
       2.6.0-test4-nick10       107.7%         0.2%

System time of kernbench is back to what it would be with virgin, or
actually a little less. Elapsed time is still up a little bit, along
with user time, but it's getting pretty close.

Have you looked at Rick Lindsley's schedstat patches? I don't have a
totally up-to-date version, but that might give us a better idea of
what's going on wrt migrations, balancing, etc.

I'll try to get together a broader set of benchmarks and hammer on this
some more ...

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/