On 06/29/2012 08:55 AM, Ingo Molnar wrote:
* Hillf Danton <dhillf@xxxxxxxxx> wrote:
On Thu, Jun 28, 2012 at 10:53 PM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
Unless you're going to listen to feedback I give you, I'm
going to completely stop reading your patches, I don't give
a rats arse you work for the same company anymore.
Are you brought up, Peter, in dirty environment with mind
polluted?
You do not seem to be aware of the history of this patch-set,
I suspect Peter got "polluted" by Andrea ignoring his repeated
review feedbacks...
AFAIK, Andrea answered many of Peter's request by reducing the memory
overhead, adding documentation and changing the scheduler integration.
When someone plants 'crap' too much in his comments, its not a surprise
that some will get ignored. Moreover, I don't think the decent comments
got ignored, sometimes both were talking in parallel lines - even in
this case, it's hard to say whether Peter's like to add ia64 support or
just like to get rid of the forceful migration as a whole.
Since it takes more time to fully understand the code than to write the
comments, I suggest to go the extra mile there and make sure the review
is crystal clear.
If his multiple rounds of polite (and extensive) review didn't
have much of an effect then maybe some amount of not so nice
shouting has more of an effect?
The other option would be to NAK and ignore the patchset, in
that sense Peter is a lot more constructive and forward looking
than a polite NAK would be, even if the language is rough.
NAK is better w/ further explanation or even suggestion about
alternatives. The previous comments were not shouts but the mother of
all NAKs.
There are some in the Linux community that adore flames but this is a
perfect example that this approach slows innovation instead of advance it.
Some developers have a thick skin and nothing gets in, others are human
and have feelings. Using a tiny difference in behavior we can do much
much better. What's works in a f2f loud discussion doesn't play well in
email.
Or alternatively:
/*
* can_nice - check if folks on lkml can be nicer&productive
* @p: person
* @nice: nice value
* Since nice isn't a negative property, nice is an uint here.
*/
int can_nice(const struct person *p, const unsigned int nice)
{
int nice_rlim = MAX_LIMIT_BEFORE_NAK;
BUG_ON(!capable(CAP_SYS_NICE));
if (nice_rlim >= task_rlimit(p, RLIMIT_NICE))
printk(KERN_INFO "Please NAK w/ decent explanation or \
submit an alternative patch);
return 0;
}
Ingo, what's your technical perspective of this particular patch?
Cheers,
Dor
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>