Messages in this thread | | | Date | Fri, 10 Aug 2007 21:47:05 +0200 | From | Willy Tarreau <> | Subject | Re: CFS review |
| |
On Fri, Aug 10, 2007 at 07:25:57PM +0200, Roman Zippel wrote: > Hi, > > On Fri, 10 Aug 2007, Michael Chang wrote: > > > On 8/10/07, Roman Zippel <zippel@linux-m68k.org> wrote: > > > Is there any reason to believe my analysis is wrong? > > > > Not yet, but if you give Ingo what he wants (as opposed to what you're > > giving him) it'll be easier for him to answer what's going wrong, and > > perhaps "fix" the problem to boot. > > > > (The scripts gives info about CPU characteristics, interrupts, > > modules, etc. -- you know, all those "unknown" variables.) > > He already has most of this information and the trace shows _exactly_ > what's going on. All this information should be more than enough to allow > an initial judgement whether my analysis is correct. > Also none of this information is needed to explain the CFS logic a little > more, which I'm still waiting for...
Roman,
fortunately all bug reporters are not like you. It's amazing how long you can resist sending a simple bug report to a developer! Maybe you consider that you need to fix the bug by yourself after you understand the code, but if you systematically refuse to return the small information Ingo asks you, we will have to wait for some more cooperative users to be hit by the same bug when 2.6.23 is released, which is stupid.
I thought you could at least understand that one developer who is used to read traces from the same tool every day will be far faster at decoding a trace from the same tool than trying to figure out what your self-maid dump means.
It's the exact same reason I ask for pcap files when people send me outputs of tcpdumps without the information I *need*.
I you definitely do not want to cooperate, stop asking for a personal explanation, and go figure by yourself how the code works. BTW, in the trace you "kindly offered" in exchange for the cfs-debug-info dump, you show several useful variables, but nothing says where they are captured. And as you can see, they're changing. That's a fantastic trace for a developer, really...
Please try to be a little bit more transparent if you really want the bugs fixed, and don't behave as if you wanted this bug to survive till -final.
Thanks, Willy
- 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/
| |