I'm terribly sorry but you have completely missed my intentions then. I was
_not_ trying to improve mainline's interactivity at all. My desire was to fix
the unfairness that mainline has, across the board without compromising
fairness. You said yourself that an approach that fixed a lot and had a small
number of regressions would be worth it. In a surprisingly ironic turnaround
two bizarre things happened. People found SD fixed a lot of their
interactivity corner cases which were showstoppers. That didn't surprise me
because any unfair design will by its nature get it wrong sometimes. The even
_more_ surprising thing is that you're now using interactivity as the
argument against SD. I did not set out to create better interactivity, I set
out to create widespread fairness without too much compromise to
interactivity. As I said from the _very first email_, there would be cases of
interactivity in mainline that performed better.
That was one user. As I mentioned in an earlier thread, the problem with email
threads on drawn out issues on lkml is that all that people remember is the
last one creating noise, and that has only been the noise from Mike for 2
weeks now. Has everyone forgotten the many many users who reported the
advantages first up which generated the interest in the first place? Why have
they stopped reporting? Well the answer is obvious; all the signs suggest
that SD is slated for mainline. It is on the path, Linus has suggested it and
now akpm is asking if it's ready for 2.6.22. So they figure there is no point
testing and replying any further. SD is ready for prime time, finalised and
does everything I intended it to. This is where I have to reveal to them the
horrible truth. This is no guarantee it will go in. In fact, this one point
that you (Ingo) go on and on about is not only a quibble, but you will call
it an absolute showstopper. As maintainer of the cpu scheduler, in its
current form you will flatly refuse it goes to mainline citing the 5% of
cases where interactivity has regressed. So people will tell me to fix it,
right?... Read on for this to unfold.
I'm sorry but this is a mis-representation to me, as I suggested on an earlier
thread where I disagree about what an interactivity estimator is. The idea of
fence posts in a clock that are passed as a way of metering out
earliest-deadline-first in a design is well established. The matrix is simply
an array designed for O(1) lookups of the fence posts. That is not the same
as "oh how much have we slept in the last $magic_number period and how much
extra time should we get for that".
And BANG there is the bullet you will use against SD from here to eternity. SD
obeys fairness at all costs. Your interactivity regression is that SD causes
progressive slowdown with load which by definition is fairness. You
repeatedly ask me to address it and there is on unfailing truth; the only way
to address it is to add unfairness to the design. So why don't I? Because the
simple fact is that any unfairness no matter how carefully administered or
metered will always have cases where it's wrong. Look at the title of this
email for example - it's yet another exploit for the mainline sleep/run
mechanism. This does _not_ mean I'm implying people are logging into servers
and running ./tenp to hang the machine. What it demonstrates is a way of
reproducing the scenario which is biting people with real world loads. It's
entirely believable that a simple p2p app could be behaving like tenp, only
generating a small load and it could take ages to log in and use the console.
Willy has complained this is why people stick to 2.4. Sure I can create
interactivity tweaks worse than anyone else. I will not, though, because that
precisely undoes what is special about SD. It never looks backwards, and is
predictable to absurdity. So you'll argue that mainline can manage it
below...
I have yet to see someone find an "exploit" for SD's current design. Mainline
is all about continually patching up the intrinsic design (and fixing this
one test case is not the be all and end all).
Well you see a race. I do not. I see a flat predictable performance from SD
where there will always be slowdown with load. I have no intention of
changing that. Mike is making an admirable attempt to fix issues as they are
pointed out. You say there are no regressions but I see absolutely no testers
of his patches besides himself and you. If I introduce any unfairness based
on sleep behaviour into SD I'll be undoing the whole point of the design and
end up chasing new regressions. So I won't quibble over the numbers. SD has
produced a lot of improvements and fairness that mainline struggles with ever
increasing patches to emulate, but SD does so at the expense of proportional
slowdown with load. At least I accept that and will no longer put my health
at risk trying to "fix" it by "breaking" it. SD is done.
I feel sorry for the many users out there who are simply "waiting for it to
end up in mainline" who just discovered you will veto it on that basis.
lwn.net had it wrong; this was far more painful than any previous attempt to
get anything into mainline.
My health has been so badly affected by this that I've been given an ultimatum
and must turn my computer off till I get well now which may be weeks. I
already know the massive flameage and last-word comments that are likely to
be fired off before the inevitable decision to veto it.
さようなら
--
-ck
-
