Mike Galbraith wrote:
On Wed, 2006-03-22 at 09:51 +1100, Peter Williams wrote:
Mike Galbraith wrote:
On Tue, 2006-03-21 at 13:59 +0100, Willy Tarreau wrote:
That would suit me perfectly. I think I would set them both to zero.
It's not clear to me what workload they can help, it seems that they
try to allow a sometimes unfair scheduling.
Correct. Massively unfair scheduling is what interactivity requires.
Selective unfairness not massive unfairness is what's required. The
hard part is automating the selectiveness especially when there are
three quite different types of task that need special treatment: 1) the
X server, 2) normal interactive tasks and 3) media streamers; each of
which has different behavioural characteristics. A single mechanism
that classifies all of these as "interactive" will unfortunately catch a
lot of tasks that don't belong to any one of these types.
Yes, selective would be nice, but it's still massively unfair that is
required. There is no criteria available for discrimination, so my
patches don't even try to classify, they only enforce the rules. I
don't classify X as interactive, I merely provide a mechanism which
enables X to accumulate the cycles an interactive task needs to be able
to perform by actually _being_ interactive, by conforming to the
definition of sleep_avg.
That's what I mean by classification :-)
Fortunately, it uses that mechanism. I do
nothing more than trade stout rope for good behavior. I anchor one end
to a boulder, the other to a task's neck. The mechanism is agnostic.
The task determines whether it gets hung or not, and the user determines
how long the rope is.
I view that as a modification (hopefully an improvement) of the
classification rules :-). In particular, a variation in the persistence
of a classification and the criteria for losing/downgrading it.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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]