From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932349AbbIUOAI (ORCPT ); Mon, 21 Sep 2015 10:00:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42641 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932166AbbIUOAG (ORCPT ); Mon, 21 Sep 2015 10:00:06 -0400 Date: Mon, 21 Sep 2015 15:57:04 +0200 From: Oleg Nesterov To: Raymond Jennings Cc: Linus Torvalds , Kyle Walker , Christoph Lameter , Michal Hocko , Andrew Morton , David Rientjes , Johannes Weiner , Vladimir Davydov , linux-mm , Linux Kernel Mailing List , Stanislav Kozina , Tetsuo Handa Subject: Re: can't oom-kill zap the victim's memory? Message-ID: <20150921135704.GA17804@redhat.com> References: <1442512783-14719-1-git-send-email-kwalker@redhat.com> <20150919150316.GB31952@redhat.com> <20150920125642.GA2104@redhat.com> <55FF03F4.6000904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FF03F4.6000904@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/20, Raymond Jennings wrote: > > On 09/20/15 11:05, Linus Torvalds wrote: >> >> which can be called from just about any context (but atomic >> allocations will never get here, so it can schedule etc). > > I think in this case the oom killer should just slap a SIGKILL on the > task and then back out, and whatever needed the memory should just wait > patiently for the sacrificial lamb to commit seppuku. Not sure I understand you correctly, but this is what we currently do. The only problem is that this doesn't work sometimes. > Also, I observed that a task in the middle of dumping core doesn't > respond to signals while it's dumping, How did you observe this? The coredumping is killable. Although yes, we have problems here in oom condition. In particular with CLONE_VM tasks. Oleg.