From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org 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: Sat, 9 Apr 2016 13:39:30 +0900 [thread overview] Message-ID: <201604091339.FAJ12491.FVHQFFMSJLtOOO@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20160408115033.GH29820@dhcp22.suse.cz> 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. 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. > 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. 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" while the reality of customers is that "I'm not skillful enough to catch the problematic behavior and make a reproducer" or "I have a little skill but I'm not permitted to modify my systems for reporting the problematic behavior". If you listen to me, I don't need to do such thing. It is very very sad.
WARNING: multiple messages have this Message-ID (diff)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org 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: Sat, 9 Apr 2016 13:39:30 +0900 [thread overview] Message-ID: <201604091339.FAJ12491.FVHQFFMSJLtOOO@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20160408115033.GH29820@dhcp22.suse.cz> 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. 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. > 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. 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" while the reality of customers is that "I'm not skillful enough to catch the problematic behavior and make a reproducer" or "I have a little skill but I'm not permitted to modify my systems for reporting the problematic behavior". If you listen to me, I don't need to do such thing. It is very very sad. -- 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-09 4:39 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 ` Tetsuo Handa [this message] 2016-04-09 4:39 ` [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skipregular " Tetsuo Handa 2016-04-11 12:02 ` Michal Hocko 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=201604091339.FAJ12491.FVHQFFMSJLtOOO@I-love.SAKURA.ne.jp \ --to=penguin-kernel@i-love.sakura.ne.jp \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=oleg@redhat.com \ --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.