From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751110AbcGMLOv (ORCPT ); Wed, 13 Jul 2016 07:14:51 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38794 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750941AbcGMLOp (ORCPT ); Wed, 13 Jul 2016 07:14:45 -0400 Date: Wed, 13 Jul 2016 13:14:26 +0200 From: Michal Hocko To: Jerome Marchand Cc: Mikulas Patocka , Ondrej Kozina , Stanislav Kozina , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: System freezes after OOM Message-ID: <20160713111426.GG28723@dhcp22.suse.cz> References: <57837CEE.1010609@redhat.com> <9be09452-de7f-d8be-fd5d-4a80d1cd1ba3@redhat.com> <20160712064905.GA14586@dhcp22.suse.cz> <1e31eea2-beb4-5734-c831-0c1753f0115a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e31eea2-beb4-5734-c831-0c1753f0115a@redhat.com> 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 10:35:01, Jerome Marchand wrote: > On 07/13/2016 01:44 AM, Mikulas Patocka wrote: > > The problem of swapping to dm-crypt is this. > > > > The free memory goes low, kswapd decides that some page should be swapped > > out. However, when you swap to an ecrypted device, writeback of each page > > requires another page to hold the encrypted data. dm-crypt uses mempools > > for all its structures and pages, so that it can make forward progress > > even if there is no memory free. However, the mempool code first allocates > > from general memory allocator and resorts to the mempool only if the > > memory is below limit. > > > > So every attempt to swap out some page allocates another page. > > > > 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. > > There is a quite recent sysctl vm knob that I believe can help in this > case: watermark_scale_factor. If you increase this value, kswapd will > start paging out earlier, when there might still be enough free memory. > > Ondrej, have you tried to increase /proc/sys/vm/watermark_scale_factor? I suspect this would just change the timing or the real problem gets hidden. -- Michal Hocko SUSE Labs