On Tue, Apr 17, 2007 at 11:24:22AM +0200, Ingo Molnar wrote: > > * William Lee Irwin III <[EMAIL PROTECTED]> wrote: > > > [...] Also rest assured that the tone of the critique is not hostile, > > and wasn't meant to sound that way. > > ok :) (And i guess i was too touchy - sorry about coming out swinging.) > > > Also, given the general comments it appears clear that some > > statistical metric of deviation from the intended behavior furthermore > > qualified by timescale is necessary, so this appears to be headed > > toward a sort of performance metric as opposed to a pass/fail test > > anyway. However, to even measure this at all, some statement of > > intention is required. I'd prefer that there be a Linux-standard > > semantics for nice so results are more directly comparable and so that > > users also get similar nice behavior from the scheduler as it varies > > over time and possibly implementations if users should care to switch > > them out with some scheduler patch or other. > > yeah. If you could come up with a sane definition that also translates > into low overhead on the algorithm side that would be great!
How's this: If you're running two identical CPU hog tasks A and B differing only by nice level (Anice, Bnice), the ratio cputime(A)/cputime(B) should be a constant f(Anice - Bnice). Other definitions make things hard to analyze and probably not well-bounded when confronted with > 2 tasks. I -think- this implies keeping a separate scaled CPU usage counter, where the scaling factor is a trivial exponential function of nice level where f(0) == 1. Then you schedule based on this scaled usage counter rather than unscaled. I also suspect we want to keep the exponential base small so that the maximal difference is 10x-100x. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
