From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: linux-mm@kvack.org, rientjes@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, oleg@redhat.com Subject: Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular OOM killer path Date: Mon, 11 Apr 2016 14:02:38 +0200 [thread overview] Message-ID: <20160411120238.GF23157@dhcp22.suse.cz> (raw) In-Reply-To: <201604091339.FAJ12491.FVHQFFMSJLtOOO@I-love.SAKURA.ne.jp> On Sat 09-04-16 13:39:30, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Fri 08-04-16 20:19:28, Tetsuo Handa wrote: > > > I looked at next-20160408 but I again came to think that we should remove > > > these shortcuts (something like a patch shown bottom). > > > > feel free to send the patch with the full description. But I would > > really encourage you to check the history to learn why those have been > > added and describe why those concerns are not valid/important anymore. > > I believe that past discussions and decisions about current code are too > optimistic because they did not take 'The "too small to fail" memory- > allocation rule' problem into account. In most cases they were driven by _real_ usecases though. And that is what matters. Theoretically possible issues which happen under crazy workloads which are DoSing the machine already are not something to optimize for. Sure we should try to cope with them as gracefully as possible, no questions about that, but we should try hard not to reintroduce previous issues during _sensible_ workloads. > If you ignore me with "check the history to learn why those have been added > and describe why those concerns are not valid/important anymore", I can do > nothing. What are valid/important concerns that have higher priority than > keeping 'The "too small to fail" memory-allocation rule' problem and continue > telling a lie to end users? Please enumerate such concerns. I feel like we are looping in a circle and I do not want to waste my time repeating arguments which were already mentioned several times. I have already told you that you have to justify potentially disruptive changes properly. So far you are more focused on extreme cases while you do not seem to care all that much about those which happen most of the time. We surely do not want to regress there. If I am telling you to study the history of our heuristics it is to _help_ you understand why they have been introduced so that you can argue with the reasoning and/or come up with improvements. Unless you start doing this chances are that your patches will not see overly warm welcome. > > Your way of throwing a large patch based on an extreme load which is > > basically DoSing the machine is not the ideal one. > > You are not paying attention to real world's limitations I'm facing. So far I haven't seen any _real_world_ example from you, to be honest. All I can see is hammering the system with some DoS scenarios which triggered different corner cases in the behavior. Those are good to make us think about our limitations and think for longterm solutions. > I have to waste my resource trying to identify and fix on behalf of > customers before they determine the kernel version to use for their > systems, for your way of thinking is that "We don't need to worry about > it because I have never received such report" No I am not saying that. I am saying that I have never seen a _properly_ configured system to blow up in a way that would trigger pathological cases you are mentioning. And that is a big difference. You can misconfigure your system in so many ways and put it on knees without a way out. With all due respect I will not continue in this line of discussion because it doesn't lead anywhere. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: linux-mm@kvack.org, rientjes@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, oleg@redhat.com Subject: Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular OOM killer path Date: Mon, 11 Apr 2016 14:02:38 +0200 [thread overview] Message-ID: <20160411120238.GF23157@dhcp22.suse.cz> (raw) In-Reply-To: <201604091339.FAJ12491.FVHQFFMSJLtOOO@I-love.SAKURA.ne.jp> On Sat 09-04-16 13:39:30, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Fri 08-04-16 20:19:28, Tetsuo Handa wrote: > > > I looked at next-20160408 but I again came to think that we should remove > > > these shortcuts (something like a patch shown bottom). > > > > feel free to send the patch with the full description. But I would > > really encourage you to check the history to learn why those have been > > added and describe why those concerns are not valid/important anymore. > > I believe that past discussions and decisions about current code are too > optimistic because they did not take 'The "too small to fail" memory- > allocation rule' problem into account. In most cases they were driven by _real_ usecases though. And that is what matters. Theoretically possible issues which happen under crazy workloads which are DoSing the machine already are not something to optimize for. Sure we should try to cope with them as gracefully as possible, no questions about that, but we should try hard not to reintroduce previous issues during _sensible_ workloads. > If you ignore me with "check the history to learn why those have been added > and describe why those concerns are not valid/important anymore", I can do > nothing. What are valid/important concerns that have higher priority than > keeping 'The "too small to fail" memory-allocation rule' problem and continue > telling a lie to end users? Please enumerate such concerns. I feel like we are looping in a circle and I do not want to waste my time repeating arguments which were already mentioned several times. I have already told you that you have to justify potentially disruptive changes properly. So far you are more focused on extreme cases while you do not seem to care all that much about those which happen most of the time. We surely do not want to regress there. If I am telling you to study the history of our heuristics it is to _help_ you understand why they have been introduced so that you can argue with the reasoning and/or come up with improvements. Unless you start doing this chances are that your patches will not see overly warm welcome. > > Your way of throwing a large patch based on an extreme load which is > > basically DoSing the machine is not the ideal one. > > You are not paying attention to real world's limitations I'm facing. So far I haven't seen any _real_world_ example from you, to be honest. All I can see is hammering the system with some DoS scenarios which triggered different corner cases in the behavior. Those are good to make us think about our limitations and think for longterm solutions. > I have to waste my resource trying to identify and fix on behalf of > customers before they determine the kernel version to use for their > systems, for your way of thinking is that "We don't need to worry about > it because I have never received such report" No I am not saying that. I am saying that I have never seen a _properly_ configured system to blow up in a way that would trigger pathological cases you are mentioning. And that is a big difference. You can misconfigure your system in so many ways and put it on knees without a way out. With all due respect I will not continue in this line of discussion because it doesn't lead anywhere. -- Michal Hocko SUSE Labs -- 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>
next prev parent reply other threads:[~2016-04-11 12:02 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-06 14:13 [PATCH 0/3] oom reaper follow ups v1 Michal Hocko 2016-04-06 14:13 ` Michal Hocko 2016-04-06 14:13 ` [PATCH 1/3] mm, oom: move GFP_NOFS check to out_of_memory Michal Hocko 2016-04-06 14:13 ` Michal Hocko 2016-04-06 14:13 ` [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path Michal Hocko 2016-04-06 14:13 ` Michal Hocko 2016-04-07 11:38 ` Tetsuo Handa 2016-04-07 11:38 ` Tetsuo Handa 2016-04-08 11:19 ` Tetsuo Handa 2016-04-08 11:19 ` Tetsuo Handa 2016-04-08 11:50 ` Michal Hocko 2016-04-08 11:50 ` Michal Hocko 2016-04-09 4:39 ` [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular " Tetsuo Handa 2016-04-09 4:39 ` Tetsuo Handa 2016-04-11 12:02 ` Michal Hocko [this message] 2016-04-11 12:02 ` Michal Hocko 2016-04-11 13:26 ` [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular " Tetsuo Handa 2016-04-11 13:26 ` Tetsuo Handa 2016-04-11 13:43 ` Michal Hocko 2016-04-11 13:43 ` Michal Hocko 2016-04-13 11:08 ` Tetsuo Handa 2016-04-13 11:08 ` Tetsuo Handa 2016-04-08 11:34 ` Michal Hocko 2016-04-08 11:34 ` Michal Hocko 2016-04-08 13:14 ` Michal Hocko 2016-04-08 13:14 ` Michal Hocko 2016-04-06 14:13 ` [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper Michal Hocko 2016-04-06 14:13 ` Michal Hocko 2016-04-07 11:55 ` Tetsuo Handa 2016-04-07 11:55 ` Tetsuo Handa 2016-04-08 11:34 ` Michal Hocko 2016-04-08 11:34 ` Michal Hocko 2016-04-16 2:51 ` Tetsuo Handa 2016-04-17 11:54 ` Michal Hocko 2016-04-18 11:59 ` Tetsuo Handa 2016-04-19 14:17 ` Michal Hocko 2016-04-19 15:07 ` Tetsuo Handa 2016-04-19 19:32 ` Michal Hocko 2016-04-08 13:07 ` Michal Hocko 2016-04-08 13:07 ` Michal Hocko
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=20160411120238.GF23157@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=oleg@redhat.com \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=rientjes@google.com \ /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.