At 10:40 AM 1/8/2006 +1100, Peter Williams wrote:
Mike Galbraith wrote:
One slight variation of your scheme would be to measure the average
length of the CPU runs that the task does (i.e. how long it runs
without voluntarily relinquishing the CPU) and not allowing them to
defer the shift to the expired array if this average run length is
greater than some specified value. The length of this average for each
task shouldn't change with system load. (This is more or less saying
that it's ok for a task to stay on the active array provided it's
unlikely to delay the switch between the active and expired arrays for
very long.)
Average burn time would indeed probably be a better metric, but that
would require doing bookkeeping is the fast path.
Most of the infrastructure is already there and the cost of doing the
extra bits required to get this metric would be extremely small. The
hardest bit would be deciding on the "limit" to be applied when deciding
whether to let a supposed interactive task stay on the active array.
Yeah, I noticed run_time when I started implementing my first cut. (which
is of course buggy)
By the way, it seems you have your own scheduler versions? If so are you
interested in adding them to the collection in PlugSched?
No, I used to do a bunch of experimentation in fairness vs interactivity,
but they all ended up just trading one weakness for an other.
-Mike
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
