> Andi will have to prove his points by coming up with competing benchmark 
quoted text
> results - 

My point was really: "don't merge based on bogus benchmarks" or
perhaps better put: every time you see a benchmark result turn on your
brain and make sure it is really measuring something that makes sense
and also "don't put results from bogus benchmarks into change logs"

I actually don't have a big issue with the patches themselves (they
seem reasonably clean so they don't make the code worse, although I
don't think they are a significant improvement over the previous code
either), just  with the methology they were submitted.

quoted text
> I dont really understand the negativism that comes from Andi - he was

I object to using bogus benchmarks.

quoted text
> very much aware of the various iterations and benchmarks you did when 
> developing this rather cool feature: he participated in those threads 
> and was Cc:-ed as well. The "100% bogus benchmark with the most 

The initial "1...n" benchmark after which you merged the patch
definitely fit my "bogus" description. If there was a later better one I
had missed that indeed, sorry and I don't remember being cc'ed on one
such (except in Alexander's latest answer which satisfied me)

-Andi


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/