Re: [RFC] [Patch 4/4] lock contention tracking slimmed down

From: Martin Peschke
Date: Fri Jun 08 2007 - 12:08:44 EST

Ingo Molnar wrote:
if the infrastructure your are advocating does not allow us to keep the existing output then it's simply not flexible enough.

Let's be precise. If "keep the existing output" means any format change is
unacceptible to you, then I broke things. If it means that my method provides
data equivalent in respect of content, then I didn't break the lock contention

Why on earth are you even arguing about this?
> A "cleanup" should not change the output, simple as that.
> Do a patch that has the _same_ output and then we can
see whether it's a good patch. You made the same mistake with your /proc/timer_stats cleanups.

We got to be careful here. My other proposal was doomed because timerstat became kernel ABI in the meantime. We won't break the kernel ABI. I was late, as simple as that.

The lock contention stuff isn't kernel ABI yet. This is -mm code, stuff
intented for a wider audience and discussion. It should be perfectly fine
to scrutinize kernel ABI additions before we get beyond the point of no return.

I dont like NACK-ing patches but you seem to be missing the basic precondition of cleanups: no functional effect to the code, and certainly no change in output.

I don't see the point of judging something by goals that have not been set.
I have advertised my patches as: same purpose, different or generalised method,
differences in output format, output equivalent in respect of content,
much more code sharing.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at