Re: [patch -mm 08/18] oom: badness heuristic rewrite

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

Hi Andrew,

> > I've already explained the reason. 1) all-of-rewrite patches are 
> > always unacceptable. that's prevent our code maintainance.
> 
> No, we'll sometime completely replace implementations.  There's no hard
> rule apart from "whatever makes sense".  If wholesale replacement makes
> sense as a patch-presentation method then we'll do that.

Have you review the actual patches? And No, I don't think "complete 
replace with no test result" is adequate development way.

And, When developers post large patch set, Usually _you_ request show
demonstrate result. I haven't seen such result in this activity.

I agree OOM is invoked from various callsite (because page allocator is 
called from various),  triggered from various memory starvation and/or 
killable userland processes are also vary various. So, I don't think 
the patch author must do 100% corvarage test.

And I can say, I made some brief test case for confirming this and
I haven't seen critical fault. 

However, It doesn't give any reason to avoid code review and violate
our development process.


> > 2) no justification
> > patches are also unacceptable. you need to write more proper patch descriptaion
> > at least.
> 
> The descriptions look better than usual from a quick scan.  I haven't
> really got into them yet.
> 
> 
> And I'm going to have to get into it because of you guys' seeming
> inability to get your act together.

Inability? What do you mean inability? Almost all developers cooperate 
for making stabilized kernel. Is this effort inability? or meaningless?

Actually, the descriptions doesn't looks better really. We sometimes
ask him
 - which problem occur? how do you reproduce it?
 - which piece solve which issue?
 - how do you measure side effect?
 - how do you mesure or consider other workload user

But I got only the answer, "My patch is best. resistance is futile". that's
purely Baaaad.

At least, All of the patch author must to write the code intention. otherwise
how do we review such code? guessing intention often makes code misparse
and allow to insert bug. if the patch is enough small, it is not big problem.
we don't makes misparse so often. but if it's large, the big problem.

Again, I don't think we can't make separate the patch as individual parts
and I don't think to don't be able to write each changes intention.


> The unsubstantiated "nack"s are of no use and I shall just be ignoring
> them and making my own decisions.  If you have specific objections then
> let's hear them.  In detail, please - don't refer to previous
> conversations because that's all too confusing - there is benefit in
> starting again.

OK. I don't have any reason to confuse you. I'll fix me. My point is
really simple. The majority OOM user are in desktop. We must not ignore
them. such as

 - Any regression from desktop view are unacceptable
 - Any incompatibility of no desktop improvement are unacceptable
 - Any refusing bugfix are unacceptable
 - Any refusing reviewing are unacceptable (IOW, must get any developers ack.
   I'm ok even if they don't include me)

In other word, every heuristic change have to be explained why the patch
improve desktop or no side-effect desktop.
(ah, ok. for cpuset change is one of exception. desktop user definitely
don't use it)

I and any other reviewer only want to confirm the have have no significant
regression. All of patch authoer have to help this, I think.


> I expect I'll be looking at the oom-killer situation in depth early
> next week.  It would be useful if between now and then you can send
> any specific, detailed and actionable comments which you have.

1) fix bugs at fist before making new feature (a.k.a new bugs)
2) don't mix bugfix and new feature
3) make separate as natural and individual piece
4) keep small and reviewable patch size
5) stop ugly excuse, instead repeatedly rewrite until get anyone ack
6) don't ignore another developers bug report

Which is unactionable? I just don't understand :/
I didn't hope says the same thing twice and he repeatedly ignore
my opinion, thus, he got short answer. I didn't think this is inadequate
beucase he can google past mail.

The fact is, I and (gessing) all other developer don't get any pressure 
from our campany because enterprise vendor don't interest oom. We are 
making time by chopping our private time, for helping impvoe his patch. 
Beucase we know current oom logic doesn't fit nowadys modern desktop
environment and we surely hope to remove such harm.

However he repeatedly attach our goodwill and blame our tolerance. 
but also repeatedly said "My workload is important than other!".
Then, I got upset really.

The fact is, all of good developer never says "my workload is most
important in the world", it makes no sense and insane. I really hate
such selfish.


And No. I wouldn't hope to continue full review during the author refuse
to hear. Kidding me. Instead, I'll do cherry-picking good piece from the 
sludge at-random patches and push you them. I think that makes everybody 
happy, people get improvement, DaveR get the merge, and I'll free from 
this frustration source. Of cource, I'll refrect your review result 
if you can get reviewing time.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>