On Thu, 2007-10-25 at 13:36 -0400, Steven Rostedt wrote: > > Yep, -rt2 (and -rt3) are both horrible too. That's why I'm working on a > sched-domain version now to handle that. Excellent. I'm not 100% sure I've got the "mingo lingo" ;) down enough to know if sched_domains are the best fit, but I think in concept that makes a lot of sense (as we have discussed on IRC). I am thinking that we want to treat the rt.highest_prio/cpupri stuff to the "cpuset" mentality, just like Ingo suggested for the rto masks. If sched_domains are those beasts, then great. > > > > > 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. Fully agree. > > > > > > > > > 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. True, but as of now its a singular domain ;) And even so, I still think a cpupri like algorithm can be potentially useful even if we utilize finer grained domains. That is, unless the membership becomes sufficiently small (maybe < 4 CPUs?) where the lower-overhead linear search will just always trounce the larger overhead of cpupri_set(). > 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. Agreed. Looking forward to reviewing your work here. :) Regards, -Greg
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- [PATCH 0/3] RT: balance rt tasks enhancements v6
- From: Gregory Haskins <[email protected]>
- [PATCH 3/3] RT: CPU priority management
- From: Gregory Haskins <[email protected]>
- Re: [PATCH 3/3] RT: CPU priority management
- From: Steven Rostedt <[email protected]>
- Re: [PATCH 3/3] RT: CPU priority management
- From: Gregory Haskins <[email protected]>
- Re: [PATCH 3/3] RT: CPU priority management
- From: Steven Rostedt <[email protected]>
- [PATCH 0/3] RT: balance rt tasks enhancements v6
- Prev by Date: Re: [PATCH] Wipe out traditional opt from x86_64 Makefile
- Next by Date: Re: [PATCH 0/3] x86: unify crash_32/64.c
- Previous by thread: Re: [PATCH 3/3] RT: CPU priority management
- Next by thread: [PATCH]fs: Fix to correct the mbcache entries counter
- Index(es):
 |