-- On Thu, 25 Oct 2007, Gregory Haskins wrote: > Oh crap. I just realized this is an older version of the patch..mustv'e > forgot to refresh...grr. Ill send out the refreshed one. Been there, done that ;-) > > But anyway, I digress. > > On Thu, 2007-10-25 at 11:27 -0400, Steven Rostedt wrote: > > > > > The cpu_priority and the cp->lock will be aboslutely horrible for > > cacheline bouncing. > > In the form presented here in this email, perhaps. I think you will see > some significant improvements in the refreshed version. The big change > is that the global lock is gone. > > > Ironically, this will kill performance for the very > > machines this code is to help with. The larger the number of CPUs you > > have the more cacheline bouncing this code will create. > > Don't forget: The same is precisely true for the current -rt2 > algorithm. For instance, the -rt2 algorithm aside from being linear in > general, scales cacheline bouncing linearly as well. Each cpu is going > to trash rq->rt.highest_prio and then we will walk them for each scan. Yep, -rt2 (and -rt3) are both horrible too. That's why I'm working on a sched-domain version now to handle that. > > The fact is, you can't maintain a global dynamic policy without bouncing > cachelines, period. But hopefully we can minimize it, and I just want > to see the fastest code here. Well, we need a balance between cacheline hits, and where to pull from. As performance goes, the two are inverse perportional. The secret is to find a nice middle ground. > > > > > I still don't see the benefit from the cpupri code. > > I still owe you timing data, but at this juncture I think I can beat > linear (especially as we start throwing in big-iron) ;) I originally > got involved in this scheduler rework from observations of poor scaling > on our 8/16-ways, so I want it to scale as much as you ;) If this alg > doesn't pan out, that's cool. But I think it will in the end. Linear > algs in the fast path just make my skin crawl. Perhaps it will still be > the best design in the end, but I am not giving up that easy until I > prove it to myself. It's only linear in respect to the size of the domain or cpus allowed. Any 8/16 way boxes worried about cacheline bouncing need to reign in on the cpus allowed mask. Otherwise, we would simply have bouncing anyway with the tasks themselves. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
