Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [patch][rfc] quell interactive feeding frenzy | Date | Sun, 16 Apr 2006 09:22:59 +1000 |
| |
On Sunday 16 April 2006 06:45, Al Boldi wrote: > Con Kolivas wrote: > > Thanks for bringing this to my attention. A while back I had different > > management of forked tasks and merged it with PF_NONSLEEP. Since then > > I've changed the management of NONSLEEP tasks and didn't realise it had > > adversely affected the accounting of forking tasks. This patch should > > rectify it. > > Congrats! > > Much smoother, but I still get this choke w/ 2 eatm 9999 loops running:
> 9 MB 783 KB eaten in 130 msec (74 MB/s) > 9 MB 783 KB eaten in 2416 msec (3 MB/s) <<<<<<<<<<<<< > 9 MB 783 KB eaten in 197 msec (48 MB/s)
> You may have to adjust the kb to get the same effect.
I've seen it. It's an artefact of timekeeping that it takes an accumulation of data to get all the information. Not much I can do about it except to have timeslices so small that they thrash the crap out of cpu caches and completely destroy throughput.
The current value, 6ms at 1000HZ, is chosen because it's the largest value that can schedule a task in less than normal human perceptible range when two competing heavily cpu bound tasks are the same priority. At 250HZ it works out to 7.5ms and 10ms at 100HZ. Ironically in my experimenting I found the cpu cache improvements become much less significant above 7ms so I'm very happy with this compromise.
Thanks!
-- -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/
| |