lkml.org 
[lkml]   [2000]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] proposed scheduler enhancements and fixes
On Sun, 27 Feb 2000, Ingo Molnar wrote:

>you can find Andrew Tridgell's dbench at:
>
> ftp://samba.org/pub/tridge/dbench/

Thanks for the pointer.

>Just getting 'good feedback' is not enough when changing the scheduler,
>lat_ctx and other micro-benchmarks are important and depend on scheduling

Am I right assuming lat_ctx -s 0 2 spawns two threads that only ping pong
all the time at maximal rate on a pipe to benchmark the speed of
schedule() (not the behaviour of the SMP scheduler!)? Such bench is single
threaded, the pipe don't even use the normal wakeup but it only calls
schedule() strightforward so I don't think my changes can affect such a
benchark. Maybe I am missing something...

Anyway in general I don't mind to have a some usec slower SMP wakeup
latency for interactive tasks if very CPU intensive tasks gets improved a
lot by my changes (thus global performances improves). Here the numbers
about my changes:

On Mon, 7 Feb 2000, Peter Waltenberg wrote:
>
>Date: Mon, 07 Feb 2000 13:02:27 +1000 (EST)
>From: Peter Waltenberg <peterw@surf.dascom.com>
>Reply-To: peterw@dascom.com
>To: andrea@suse.de
>Subject: Scheduler mod for 2.3.42
>Parts/Attachments:
> 1 Shown 40 lines Text
> 2 ~1.1 KB Application
>----------------------------------------
>
>O.K. quite a noticeable improvement. I havn't cc'd linux-kernel, basically I'm
>pretty busy right now and don't really need spam. But if you need to reference
>these results go ahead.
>
>I've attached a revised test program. This does two types of loops, once cache
>intensive, the other simply CPU intensive with a low cache footprint.
>This means we can eliminate problems that aren't due soley to cache use.
>
>The test code simply times how long 50k loops of a Cache and CPU bound process
>take. Times are seconds, and have a +/- 1 second rounding error. Smaller
>numbers
>are better.
>
>2.3.42 Console X X +xosview
>
>Cache 20-21 14 14
>CPU 14 15 15
>
>That ones REALLY interesting. The cache intensive process got FASTER with more
>load. I suspect it was being kicked BACK onto the original CPU with the cache
>still hot.
>
>
>2.3.42+pat Console X X +xosview
>
>Cache 12 10-11 10
>CPU 15 14-15 14-15
>
>
>Even with your patch, I'd say the scheduler is a little broken, The tendency
>for
>the task to get faster with higher load is not a good sign.
>
>Note that with your patch the hog process is still hopping CPU's, it's just
>spending more time on each CPU. So I suspect there's quite a bit more
>performance that can be gained.
>
>Thanks
>Peter
>----------------------------------
>Peter Waltenberg
>----------------------------------
>
> [ Part 2, Application/OCTET-STREAM (Name: "hog2.c") 1.1KB. ]
> [ Cannot display this part. Press "V" then "S" to save in a file. ]
>
>

I believe Linux is going to be used a lot for very CPU intensive
computation/simulation and I care very much to not waste CPU power by
trahsing the caches all the time.

>heavily. Could you check wether your patch causes the lat_ctx slowdown
>Dimitris noticed?

I'll check ASAP. (Dimitris if you'll check too please take me in CC so we
won't duplicate efforts ;).

>i believe we have two problems and they are unrelated: lat_ctx
>micro-slowdown and IO performance slowdown.

Probably. But it doesn't seems to me that the lat_ctx can be caused by my
reschedule_idle changes since the wakeup shouldn't happen in first place
there.

Just and idea maybe it's the wakeup_sync thing that harms lat_ctx? It
shouldn't but that would be at least an obvious change in the path run by
the lat_ctx bench. But that's not a 2.3.4x change IIRC.

Andrea


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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.056 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site