On Fri, 4 Jun 2010, KOSAKI Motohiro wrote: > Have you review the actual patches? And No, I don't think "complete > replace with no test result" is adequate development way. > I have repeatedly said that the oom killer no longer kills KDE when run on my desktop in the presence of a memory hogging task that was written specifically to oom the machine. That's a better result than the current implementation and was discussed thoroughly during the discussion on this mailing list back in February that inspired this rewrite to begin with. I don't think there's any mystery there since you've referred to that change specifically for KDE in this thread yourself. > And, When developers post large patch set, Usually _you_ request show > demonstrate result. I haven't seen such result in this activity. > You want to see a log that says "Killed process 1234 (memory-hogger)..." instead of "Killed process 1234 (kdeinit)..."? You've supported the change from total_vm to rss as a baseline to begin with. And after all this discussion, this is the first time you've ever said you wanted to see that type of log or anything like it. > However, It doesn't give any reason to avoid code review and violate > our development process. > Nobody is avoiding code review here, that's pretty obvious, and I have no idea you're referring to when you're saying I'm violating the development process because this happens to rewrite an entire function and requires a new user interface and callsite fixups to be meaningful. You specifically asked me to push the forkbomb detector in a different patch and I did that because it makes sense to seperate that heuristic, but even then you just wrote "nack" and haven't responded with why even after I've replied twice asking. I'm really confused this behavior. > > 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? > I think he's saying that he expects that we should be able to work cooperateively in resolving any differences that we have in a respectful and technical manner on this list. But I'll also add my two cents in that and say that we should probably be leaving maintainer duties up to the actual -mm tree maintainer, he knows the development process you're talking about pretty well. > Actually, the descriptions doesn't looks better really. We sometimes > ask him > - which problem occur? how do you reproduce it? KDE gets killed, memory hogger doesn't. Run memory hogger on your desktop. KOSAKI, this isn't a surprise to you. If this is your objection, I can certainly elaborate more in the changelog but up until yesterday you've never said you have a problem with it so how am I supposed to make any forward progress on this? I can't read your mind when you say "nack" and I'd like to resolve any issues that people have, but that requires that they get involved. > - which piece solve which issue? Mostly the baseline heuristic change to rss and swap, as you well know. > - how do you measure side effect? As far as the objective of the oom killer is concerned as listed in mm/oom_kill.c's header, there is no side effects. We're trying to kill a task that will free the largest amount of memory and clearly rss and swap is a better indication fo that then total_vm. > - how do you mesure or consider other workload user > The objective of the oom killer is not different for different workloads. > But I got only the answer, "My patch is best. resistance is futile". that's > purely Baaaad. > I haven't said anything new in the above, KOSAKI, you already knew all this. I'll update the changelog to include some of this information for the next posting, but I'd really hope that this isn't the major problem that you've had the entire time that we've stalled weeks on. > 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 This patchset was specifically designed to improve the oom killer's behavior on the desktop! > - Any incompatibility of no desktop improvement are unacceptable I don't understand this. > - Any refusing bugfix are unacceptable I've merged most of Oleg's work into this patchset, the problem that we're having is deciding whether any of it is -rc material or not and should be pushed first. I don't think any of it is, Oleg certainly wasn't pushing it and to date I don't believe has said it's rc material, so that's something you can talk about but I'm not refusing any bugfix. > - Any refusing reviewing are unacceptable (IOW, must get any developers ack. > I'm ok even if they don't include me) > I've been begging for you to review this. > 1) fix bugs at fist before making new feature (a.k.a new bugs) Kame already suggested a new order to the patchset that I'll be restructuring. I'm curious as to why this was removed from -mm though on your suggestion before any of this became an issue. We've yet to hear that mysterious information. > 2) don't mix bugfix and new feature Andrew said bugfixes should come first, they will in the reposting, but I don't consider any of it to be -rc material. > 3) make separate as natural and individual piece I can't keep having this conversation, the patch is broken down into one functional unit as much as possible. Please leave the maintainership of this code to Andrew who has already said entire implementation changes (in this case, a single function rewrite) is allowed if it makes sense. > 4) keep small and reviewable patch size Same as above. > 5) stop ugly excuse, instead repeatedly rewrite until get anyone ack I don't know what my ugly excuse is, but I'll be reordering the patches and sending them with an updated changelog on the badness heuristic rewrite. I hope that will satisfy all your concerns. > 6) don't ignore another developers bug report > If you have a bug report that is the result of this rewrite, please come forward with it and don't carry this out by making me guess again. > 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. > No, you've never said this is the reason why it was dropped from -mm or why it was "nack"'d early on. > 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. > What?? I don't even have a specific workload that I'm targeting with this change, I have no idea what you're referring to, we don't run much stuff on the desktop :) > 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. Again, this is just a ridiculous accusation. I have no idea what you're referring to since this rewrite is specifically addressed to fix the oom killer problems on the desktop. I work on servers and systems software, I don't have a desktop workload that I'm advocating for here, so perhaps you got me confused with someone else. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>