From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752167AbcGMMvO (ORCPT ); Wed, 13 Jul 2016 08:51:14 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:38503 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751422AbcGMMvA (ORCPT ); Wed, 13 Jul 2016 08:51:00 -0400 Date: Wed, 13 Jul 2016 14:50:51 +0200 From: Michal Hocko To: Mikulas Patocka Cc: Ondrej Kozina , Jerome Marchand , Stanislav Kozina , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: System freezes after OOM Message-ID: <20160713125050.GJ28723@dhcp22.suse.cz> References: <57837CEE.1010609@redhat.com> <9be09452-de7f-d8be-fd5d-4a80d1cd1ba3@redhat.com> <20160712064905.GA14586@dhcp22.suse.cz> <20160713111006.GF28723@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713111006.GF28723@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 13-07-16 13:10:06, Michal Hocko wrote: > On Tue 12-07-16 19:44:11, Mikulas Patocka wrote: [...] > > As long as swapping is in progress, the free memory is below the limit > > (because the swapping activity itself consumes any memory over the limit). > > And that triggered the OOM killer prematurely. > > I am not sure I understand the last part. Are you saing that we trigger > OOM because the initiated swapout will not be able to finish the IO thus > release the page in time? > > The oom detection checks waits for an ongoing writeout if there is no > reclaim progress and at least half of the reclaimable memory is either > dirty or under writeback. Pages under swaout are marked as under > writeback AFAIR. The writeout path (dm-crypt worker in this case) should > be able to allocate a memory from the mempool, hand over to the crypt > layer and finish the IO. Is it possible this might take a lot of time? I am not familiar with the crypto API but from what I understood from crypt_convert the encryption is done asynchronously. Then I got lost in the indirection. Who is completing the request and from what kind of context? Is it possible it wouldn't be runable for a long time? -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by kanga.kvack.org (Postfix) with ESMTP id C68D16B0005 for ; Wed, 13 Jul 2016 08:50:54 -0400 (EDT) Received: by mail-lf0-f70.google.com with SMTP id 33so31788093lfw.1 for ; Wed, 13 Jul 2016 05:50:54 -0700 (PDT) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com. [74.125.82.52]) by mx.google.com with ESMTPS id fk9si785233wjb.30.2016.07.13.05.50.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 05:50:53 -0700 (PDT) Received: by mail-wm0-f52.google.com with SMTP id i5so67620522wmg.0 for ; Wed, 13 Jul 2016 05:50:53 -0700 (PDT) Date: Wed, 13 Jul 2016 14:50:51 +0200 From: Michal Hocko Subject: Re: System freezes after OOM Message-ID: <20160713125050.GJ28723@dhcp22.suse.cz> References: <57837CEE.1010609@redhat.com> <9be09452-de7f-d8be-fd5d-4a80d1cd1ba3@redhat.com> <20160712064905.GA14586@dhcp22.suse.cz> <20160713111006.GF28723@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713111006.GF28723@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Mikulas Patocka Cc: Ondrej Kozina , Jerome Marchand , Stanislav Kozina , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Wed 13-07-16 13:10:06, Michal Hocko wrote: > On Tue 12-07-16 19:44:11, Mikulas Patocka wrote: [...] > > As long as swapping is in progress, the free memory is below the limit > > (because the swapping activity itself consumes any memory over the limit). > > And that triggered the OOM killer prematurely. > > I am not sure I understand the last part. Are you saing that we trigger > OOM because the initiated swapout will not be able to finish the IO thus > release the page in time? > > The oom detection checks waits for an ongoing writeout if there is no > reclaim progress and at least half of the reclaimable memory is either > dirty or under writeback. Pages under swaout are marked as under > writeback AFAIR. The writeout path (dm-crypt worker in this case) should > be able to allocate a memory from the mempool, hand over to the crypt > layer and finish the IO. Is it possible this might take a lot of time? I am not familiar with the crypto API but from what I understood from crypt_convert the encryption is done asynchronously. Then I got lost in the indirection. Who is completing the request and from what kind of context? Is it possible it wouldn't be runable for a long time? -- 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: email@kvack.org