From: "Figo.zhang" <zhangtianfei@leadcoretech.com> To: David Rientjes <rientjes@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "Figo.zhang" <figo1802@gmail.com>, lkml <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] Revert oom rewrite series Date: Mon, 15 Nov 2010 11:26:54 +0800 [thread overview] Message-ID: <4CE0A87E.1030304@leadcoretech.com> (raw) In-Reply-To: <alpine.DEB.2.00.1011141330120.22262@chino.kir.corp.google.com> >Nothing to say, really. Seems each time we're told about a bug or a >regression, David either fixes the bug or points out why it wasn't a >bug or why it wasn't a regression or how it was a deliberate behaviour >change for the better. >I just haven't seen any solid reason to be concerned about the state of >the current oom-killer, sorry. >I'm concerned that you're concerned! A lot. When someone such as >yourself is unhappy with part of MM then I sit up and pay attention. >But after all this time I simply don't understand the technical issues >which you're seeing here. we just talk about oom-killer technical issues. i am doubt that a new rewrite but the athor canot provide some evidence and experiment result, why did you do that? what is the prominent change for your new algorithm? as KOSAKI Motohiro said, "you removed CAP_SYS_RESOURCE condition with ZERO explanation". David just said that pls use userspace tunable for protection by oom_score_adj. but may i ask question: 1. what is your innovation for your new algorithm, the old one have the same way for user tunable oom_adj. 2. if server like db-server/financial-server have huge import processes (such as root/hardware access processes)want to be protection, you let the administrator to find out which processes should be protection. you will let the financial-server administrator huge crazy!! and lose so many money!! ^~^ 3. i see your email in LKML, you just said "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." http://thread.gmane.org/gmane.linux.kernel.mm/48998 so you just test your new oom_killer algorithm on your desktop with KDE, so have you provide the detail how you do the test? is it do the experiment again for anyone and got the same result as your comment ? as KOSAKI Motohiro said, in reality word, it we makes 5-6 brain simulation, embedded, desktop, web server,db server, hpc, finance. Different workloads certenally makes big impact. have you do those experiments? i think that technology should base on experiment not on imagine. Best, Figo.zhang
WARNING: multiple messages have this Message-ID (diff)
From: "Figo.zhang" <zhangtianfei@leadcoretech.com> To: David Rientjes <rientjes@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "Figo.zhang" <figo1802@gmail.com>, lkml <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] Revert oom rewrite series Date: Mon, 15 Nov 2010 11:26:54 +0800 [thread overview] Message-ID: <4CE0A87E.1030304@leadcoretech.com> (raw) In-Reply-To: <alpine.DEB.2.00.1011141330120.22262@chino.kir.corp.google.com> >Nothing to say, really. Seems each time we're told about a bug or a >regression, David either fixes the bug or points out why it wasn't a >bug or why it wasn't a regression or how it was a deliberate behaviour >change for the better. >I just haven't seen any solid reason to be concerned about the state of >the current oom-killer, sorry. >I'm concerned that you're concerned! A lot. When someone such as >yourself is unhappy with part of MM then I sit up and pay attention. >But after all this time I simply don't understand the technical issues >which you're seeing here. we just talk about oom-killer technical issues. i am doubt that a new rewrite but the athor canot provide some evidence and experiment result, why did you do that? what is the prominent change for your new algorithm? as KOSAKI Motohiro said, "you removed CAP_SYS_RESOURCE condition with ZERO explanation". David just said that pls use userspace tunable for protection by oom_score_adj. but may i ask question: 1. what is your innovation for your new algorithm, the old one have the same way for user tunable oom_adj. 2. if server like db-server/financial-server have huge import processes (such as root/hardware access processes)want to be protection, you let the administrator to find out which processes should be protection. you will let the financial-server administrator huge crazy!! and lose so many money!! ^~^ 3. i see your email in LKML, you just said "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." http://thread.gmane.org/gmane.linux.kernel.mm/48998 so you just test your new oom_killer algorithm on your desktop with KDE, so have you provide the detail how you do the test? is it do the experiment again for anyone and got the same result as your comment ? as KOSAKI Motohiro said, in reality word, it we makes 5-6 brain simulation, embedded, desktop, web server,db server, hpc, finance. Different workloads certenally makes big impact. have you do those experiments? i think that technology should base on experiment not on imagine. Best, Figo.zhang -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-15 3:27 UTC|newest] Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-11-02 1:43 [PATCH]oom-kill: direct hardware access processes should get bonus Figo.zhang 2010-11-02 1:43 ` Figo.zhang 2010-11-02 3:10 ` David Rientjes 2010-11-02 3:10 ` David Rientjes 2010-11-02 14:24 ` Figo.zhang 2010-11-02 14:24 ` Figo.zhang 2010-11-02 19:34 ` David Rientjes 2010-11-02 19:34 ` David Rientjes 2010-11-03 23:43 ` [PATCH v2]oom-kill: CAP_SYS_RESOURCE " Figo.zhang 2010-11-03 23:43 ` Figo.zhang 2010-11-03 23:47 ` David Rientjes 2010-11-03 23:47 ` David Rientjes [not found] ` <AANLkTimjfmLzr_9+Sf4gk0xGkFjffQ1VcCnwmCXA88R8@mail.gmail.com> 2010-11-04 1:38 ` Figo.zhang 2010-11-04 1:38 ` Figo.zhang 2010-11-04 1:50 ` David Rientjes 2010-11-04 1:50 ` David Rientjes 2010-11-04 2:12 ` Figo.zhang 2010-11-04 2:12 ` Figo.zhang 2010-11-04 2:54 ` David Rientjes 2010-11-04 2:54 ` David Rientjes 2010-11-04 4:42 ` Figo.zhang 2010-11-04 4:42 ` Figo.zhang 2010-11-04 5:08 ` David Rientjes 2010-11-04 5:08 ` David Rientjes 2010-11-09 11:01 ` [PATCH " KOSAKI Motohiro 2010-11-09 11:01 ` KOSAKI Motohiro 2010-11-09 12:24 ` Alan Cox 2010-11-09 12:24 ` Alan Cox 2010-11-09 21:06 ` David Rientjes 2010-11-09 21:06 ` David Rientjes 2010-11-09 21:25 ` David Rientjes 2010-11-09 21:25 ` David Rientjes 2010-11-10 14:38 ` Figo.zhang 2010-11-10 14:38 ` Figo.zhang 2010-11-10 20:50 ` David Rientjes 2010-11-10 20:50 ` David Rientjes 2010-11-09 10:41 ` [PATCH]oom-kill: direct hardware access processes " KOSAKI Motohiro 2010-11-09 10:41 ` KOSAKI Motohiro 2010-11-09 12:24 ` [PATCH v2]mm/oom-kill: " Figo.zhang 2010-11-09 12:24 ` Figo.zhang 2010-11-09 21:16 ` David Rientjes 2010-11-09 21:16 ` David Rientjes 2010-11-10 14:48 ` Figo.zhang 2010-11-10 14:48 ` Figo.zhang 2010-11-14 5:07 ` KOSAKI Motohiro 2010-11-14 5:07 ` KOSAKI Motohiro 2010-11-14 21:29 ` David Rientjes 2010-11-14 21:29 ` David Rientjes 2010-11-15 1:24 ` KOSAKI Motohiro 2010-11-15 1:24 ` KOSAKI Motohiro 2010-11-15 10:03 ` David Rientjes 2010-11-15 10:03 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-28 1:36 ` David Rientjes 2010-11-28 1:36 ` David Rientjes 2010-11-30 13:00 ` KOSAKI Motohiro 2010-11-30 13:00 ` KOSAKI Motohiro 2010-11-30 20:05 ` David Rientjes 2010-11-30 20:05 ` David Rientjes 2010-11-10 15:14 ` [PATCH v3]mm/oom-kill: " Figo.zhang 2010-11-10 15:14 ` Figo.zhang 2010-11-10 15:24 ` Figo.zhang 2010-11-10 15:24 ` Figo.zhang 2010-11-10 21:00 ` David Rientjes 2010-11-10 21:00 ` David Rientjes 2010-11-14 5:21 ` KOSAKI Motohiro 2010-11-14 5:21 ` KOSAKI Motohiro 2010-11-14 21:33 ` David Rientjes 2010-11-14 21:33 ` David Rientjes 2010-11-15 3:26 ` Figo.zhang [this message] 2010-11-15 3:26 ` [PATCH] Revert oom rewrite series Figo.zhang 2010-11-15 10:14 ` David Rientjes 2010-11-15 10:14 ` David Rientjes 2010-11-15 10:57 ` Alan Cox 2010-11-15 10:57 ` Alan Cox 2010-11-15 20:54 ` David Rientjes 2010-11-15 20:54 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 7:16 ` KOSAKI Motohiro 2011-01-04 7:51 ` [PATCH v3]mm/oom-kill: direct hardware access processes should get bonus Figo.zhang 2011-01-04 7:51 ` Figo.zhang 2011-01-04 8:28 ` KAMEZAWA Hiroyuki 2011-01-04 8:28 ` KAMEZAWA Hiroyuki 2011-01-04 8:56 ` Figo.zhang 2011-01-04 8:56 ` Figo.zhang 2011-01-06 0:55 ` KAMEZAWA Hiroyuki 2011-01-06 0:55 ` KAMEZAWA Hiroyuki 2011-01-05 3:32 ` David Rientjes 2011-01-05 3:32 ` David Rientjes 2010-11-14 5:07 [PATCH] Revert oom rewrite series KOSAKI Motohiro 2010-11-14 19:32 ` Linus Torvalds 2010-11-15 0:54 ` KOSAKI Motohiro 2010-11-15 2:19 ` Andrew Morton [not found] ` <AANLkTik_SDaiu2eQsJ9+4ywLR5K5V1Od-hwop6gwas3F@mail.gmail.com> 2010-11-15 4:41 ` Figo.zhang 2010-11-15 4:41 ` Figo.zhang 2010-11-15 6:57 ` KOSAKI Motohiro 2010-11-15 10:34 ` David Rientjes 2010-11-15 23:31 ` Jesper Juhl 2010-11-16 0:06 ` David Rientjes 2010-11-16 10:04 ` Martin Knoblauch 2010-11-16 10:33 ` Alessandro Suardi 2010-11-16 0:13 ` Valdis.Kletnieks 2010-11-16 6:43 ` David Rientjes 2010-11-16 11:03 ` Alan Cox 2010-11-16 13:03 ` Florian Mickler 2010-11-16 14:55 ` Alan Cox 2010-11-16 20:57 ` David Rientjes 2010-11-16 21:01 ` Fabio Comolli 2010-11-17 4:04 ` Valdis.Kletnieks 2010-11-16 15:15 ` Alejandro Riveira Fernández 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-28 1:45 ` David Rientjes 2010-11-30 13:04 ` KOSAKI Motohiro 2010-11-30 20:02 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 23:51 ` KOSAKI Motohiro 2010-11-14 21:58 ` David Rientjes 2010-11-15 23:33 ` Bodo Eggert 2010-11-15 23:50 ` David Rientjes 2010-11-17 0:06 ` Bodo Eggert 2010-11-17 0:25 ` David Rientjes 2010-11-17 0:48 ` Mandeep Singh Baines
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4CE0A87E.1030304@leadcoretech.com \ --to=zhangtianfei@leadcoretech.com \ --cc=akpm@osdl.org \ --cc=figo1802@gmail.com \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=rientjes@google.com \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.