|| ||David Rientjes <rientjes-AT-google.com> |
|| ||KOSAKI Motohiro <kosaki.motohiro-AT-jp.fujitsu.com> |
|| ||Re: [patch -mm 08/18] oom: badness heuristic rewrite |
|| ||Fri, 4 Jun 2010 13:57:16 -0700 (PDT)|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>, Rik van Riel <riel-AT-redhat.com>,
Nick Piggin <npiggin-AT-suse.de>, Oleg Nesterov <oleg-AT-redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu-AT-jp.fujitsu.com>,
Balbir Singh <balbir-AT-linux.vnet.ibm.com>, linux-mm-AT-kvack.org|
|| ||Article, Thread
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 email@example.com. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"firstname.lastname@example.org"> email@example.com </a>
to post comments)