From: Davide L. <da...@xm...> - 2001-11-03 22:00:19
|
On Fri, 2 Nov 2001, Hubertus Franke wrote: > * Mike Kravetz <kr...@us...> [20011031 18;12]:" > > Here's some data from TPC-H. As you can imagine, I can't post any > > actual numbers, so I'll just report the % improvement. > > > > *** Disclaimer *** this is not representative of an actual TPC-H > > run as the database is small (500MB) and is run with as much data > > in memory as possible. Hence, there is little or no I/O. It is > > my understanding that on 'real' TPC-H runs, the I/O path becomes > > a limiting factor and no scheduler impacts can be seen. > > > > -------------------------------------------------------------------- > > TPC-H - 8 CPU system. Small (500MB) database with most data > > cached and little if any I/O. > > -------------------------------------------------------------------- > > Vanilla MQ Sched Xsched > > -------------------------------------------------------------------- > > Baseline +6.2% +2.4% > > > > I'm going to try and merge your 'cache warmth' replacement for > > PROC_CHANGE_PENALTY into the LSE MQ scheduler, as well as enable > > the code to prevent task stealing during IPI delivery. This > > should still be significantly different than your design because > > MQ will still attempt to make global decisions. Results should > > be interesting. > > > Excellent idea, I think, that's the new idea that Davide brings to > the table. MQ has been around in our stuff and in the HP scheduler (Rhine). > > BTW: The reason why for the reflex MQ starts getting better with larger numbers > is because the likelihood of moving a task is going down. As i told to Mike in a previous email the reason of lower performance on certain test is due the lack of balancing tests in reschedule_idle(). What happens with this tests is that the main test thread starts creating a bunch of threads that very likely are going to sleep very soon waiting for the main test thread to issue a start event. This make get_best_cpu() to return the same cpu to all threads and, when the real test begin, there's no idle reschedule ( due the load ) to enable a decent balancing. A simple balancing hook in reschedule_idle() has made the scheduler to perform very well in this kind of tests. - Davide |