On Thu, 2007-09-13 at 00:17 +0200, Roman Zippel wrote: > The rest of the math is indeed different - it's simply missing. What is > there is IMO not really adequate. I guess you will see the differences, > once you test a bit more with different nice levels. The rounding error we now still have is accumulative over the long time but has no real effect. The only effect is that a nice level would be a little different that it would have been had the division been perfect, not dissimilar to having a small error in the divisor series to being with. (note that in order to see this little fuzz you need amazingly high context switch rates) We've measured the effect with the strongest nice levels -20 and 19, a normal loop against two yield loops (this generated 700.000 context switches per second), and the effect is <1%. Not something worth fixing IMHO (unless it comes for free). At that high switching rates the overhead of scheduling itself and caching causes more skew than this - the small error is totally swamped by the time lost scheduling. > There's a good reason > I put that much effort into maintaining a good, but still cheap average, > it's needed for a good task placement. While I agree that having this average is nice, your particular implementation has the problem that it quickly overflows u64 at which point it becomes a huge problem (a CPU hog could basically lock up your box when that happens). I solved the wrap around problem in cfs-devel, and from that base I _could_ probably maintain the average without overflow problems, but have yet to try. > There is of course more than one > way to implement this, so you'll have good chances to simply reimplement > it somewhat differently, but I'd be surprised if it would be something > completely different. Currently we have 2 approximations in place: (leftmost + rightmost) / 2 and leftmost + period/2 (where period should match the span of the tree) neither are perfect but they seem to work quite well.
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [announce] CFS-devel, performance improvements
- From: Roman Zippel <[email protected]>
- Re: [announce] CFS-devel, performance improvements
- References:
- [announce] CFS-devel, performance improvements
- From: Ingo Molnar <[email protected]>
- Re: [announce] CFS-devel, performance improvements
- From: Roman Zippel <[email protected]>
- [announce] CFS-devel, performance improvements
- Prev by Date: Re: CFS: some bad numbers with Java/database threading
- Next by Date: Re: [GIT PULL] Blackfin arch bug fixing for 2.6.23-rc6
- Previous by thread: Re: [announce] CFS-devel, performance improvements
- Next by thread: Re: [announce] CFS-devel, performance improvements
- Index(es):