Messages in this thread | | | Date | Sun, 27 Feb 2000 06:37:49 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [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/
| |