Messages in this thread | | | From | Con Kolivas <> | Subject | Re: RSDL v0.30 cpu scheduler for mainline kernels | Date | Fri, 16 Mar 2007 08:11:50 +1100 |
| |
On Friday 16 March 2007 05:58, Ray Lee wrote: > On 3/15/07, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote: > > On Thu, Mar 15, 2007 at 05:05:13PM +1100, Con Kolivas wrote: > > > On Thursday 15 March 2007 13:31, Siddha, Suresh B wrote: > > > > Just to see the % increase in number of context switches, I ran 8 > > > > infinite loops (simple while(1); 's) and with 2.6.21-rc3 I see ~70 > > > > context switches every second, whereas with RSDL I see ~530 context > > > > switches. > > > > > > Thanks. If it's just that then scaling rr interval with cpus somewhat > > > would help. If you could, the following patch just to test might > > > confirm that. -#define RR_INTERVAL ((6 * HZ / 1001) + 1) > > > +#define RR_INTERVAL ((12 * HZ / 1001) + 1) > > > > Context switches now are ~370 per second. Still much above the regular > > ~70 we see in the mainline. > > > > why do you say the rr_interval needs to be scaled with cpus? The basic > > point in RSDL is, if we have more than one same priority task on a single > > logic cpu, context switch happens every RR_INTERVAL (6 or 12 msec) > > whereas in mainline it happens every 100 msec.
No. That's what we do with mainline too. The analogue of the RR_INTERVAL in mainline is the timeslice granularity. When I wrote it (TG) I assumed that any increase in latency by lengthening this value would be offset by more cpus being available which is only partially true. I also did not assume at the time that many cpus would be used on a desktop which is now, wrong.
> With more CPUs, the context switch period can be multiplied by that > number of CPUs while still allowing all tasks the same frequency of > access to the CPU. With 4 processors, the context switch would be > 24ms, by which point we're probably reaching the point of diminishing > returns for minimizing overhead and maximizing throughput. > > > We need to minimize these context switches. > > That's a judgement call. If a synthetic benchmark degrades but other > things improve, then this, as most everything in computer science, is > yet another trade-off that needs to be evaluated. (You recognize there > is a tradeoff here, right? Some benchmarks would improve even further > if the switch time were 500ms. But that would make the system nearly > unusable in general.) > > Ray
-- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |