The problems with this argument are:
. We've pointed him at a benchmark that doesn't have the same problems.
. We've tried to explain that he's counting angels on the head of a pin,
that what he is doing is not relevant and certainly would not be taken
as justification for a scheduler redesign, which seems to be his goal.
. His defense is completely unreasonable, both from a statistical
point of view (consider his standard deviation) and from a systems
architecture point of view.
. While it would be nice for Richard if someone dissected his benchmark,
the people who can have already pruned that branch of the tree as
uninteresting, i.e., no payoff. There are a million uninteresting
things to look at - a good kernel hack quickly sorts out which ones
are worthwhile. It costs time and effort to explain the wrong paths,
using that time takes away from causes that are actually worthwhile.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/