Re: [patch] sched-2.6.0-test1-G6, interactivity changes

[Rob Landley]

On Monday 28 July 2003 18:00, Con Kolivas wrote:

> Agreed, and no doubt the smaller the timeslice the worse it is. I did a
> little experimenting with my P4 2.53 here and found that basically no
> matter how much longer the timeslice was there was continued benefit.
> However the benefit was diminishing the higher you got. If you graphed it
> out it was a nasty exponential curve up to 7ms and then there was a knee in
> the curve and it was virtually linear from that point on with only tiny
> improvements. A p3 933 behaved surprisingly similarly. That's why on
> 2.4.21-ck3 it was running with timeslice_granularity set to 10ms. However
> the round robin isn't as bad as pure timeslice limiting because if they're
> still on the active array I am led to believe there is less cache trashing.
>
> There was no answer in that but just thought I'd add what I know so far.
>
> Con

Fun.

Have you read the excellent DRAM series on ars technica?

http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part1-2.html
http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part2-1.html
http://www.arstechnica.com/paedia/r/ram_guide/ram_guide.part3-1.html

Sounds like you're thwacking into memory latency and bank switching and such.  
(Yes, you can thrash dram.  It's not as noticeable as with disk, but it's can 
be done.)

The memory bus speed will affect this a little bit, but it's not going to do 
to much for request turnaround time except make it proportionally even worse.  
Same for DDR. :)

Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/