|From:||David Miller <davem-AT-davemloft.net>|
|Subject:||Re: [tbench regression fixes]: digging out smelly deadmen.|
|Date:||Sun, 26 Oct 2008 19:34:51 -0700 (PDT)|
|Cc:||akpm-AT-linux-foundation.org, a.p.zijlstra-AT-chello.nl, efault-AT-gmx.de, jkosina-AT-suse.cz, rjw-AT-sisk.pl, mingo-AT-elte.hu, s0mbre-AT-tservice.net.ru, linux-kernel-AT-vger.kernel.org, netdev-AT-vger.kernel.org|
From: Evgeniy Polyakov <firstname.lastname@example.org> Date: Sun, 26 Oct 2008 13:05:55 +0300 > I'm not surprised there were no changes when I reported hrtimers to be > the main guilty factor in my setup for dbench tests, and only when David > showed that they also killed his sparks via wake_up(), something was > done. Now this regression even dissapeared from the list. > Good direction, we should always follow this. Yes, this situation was in my opinion a complete fucking joke. Someone like me shouldn't have to do all of the hard work for the scheduler folks in order for a bug like this to get seriously looked at. Evgeniy's difficult work was effectively ignored except by other testers who could also see and reproduce the problem. No scheduler developer looked seriously into these reports other than to say "please try to reproduce with tip" (?!?!?!) I guess showing the developer the exact changeset(s) which add the regression isn't enough these days :-/ Did any scheduler developer try to run tbench ONCE and do even a tiny bit of analysis, like the kind I did? Answer honestly... Linus even asked you guys in the private thread to "please look into it". So, if none of you did, you should all be deeply ashamed of yourselves. People like me shouldn't have to do all of that work for you just to get something to happen. Not until I went privately to Ingo and Linus with cycle counts and a full disagnosis (of every single release since 2.6.22, a whole 2 days of work for me) of the precise code eating up too many cycles and causing problems DID ANYTHING HAPPEN. This is extremely and excruciatingly DISAPPOINTING and WRONG. We completely and absolutely suck if this is how we will handle any performance regression report. And although this case is specific to the scheduler, a lot of other areas handle well prepared bug reports similarly. So I'm not really picking on the scheduler folks, they just happen to be the current example :-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds