From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753026AbcGMOVh (ORCPT ); Wed, 13 Jul 2016 10:21:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44936 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522AbcGMOV2 (ORCPT ); Wed, 13 Jul 2016 10:21:28 -0400 Date: Wed, 13 Jul 2016 10:21:07 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: Jerome Marchand , Ondrej Kozina , Stanislav Kozina , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: System freezes after OOM In-Reply-To: <20160713111426.GG28723@dhcp22.suse.cz> Message-ID: References: <57837CEE.1010609@redhat.com> <9be09452-de7f-d8be-fd5d-4a80d1cd1ba3@redhat.com> <20160712064905.GA14586@dhcp22.suse.cz> <1e31eea2-beb4-5734-c831-0c1753f0115a@redhat.com> <20160713111426.GG28723@dhcp22.suse.cz> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Jul 2016 14:21:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Jul 2016, Michal Hocko wrote: > 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. I agree - tweaking some limits would just change the probability of the bug without addressing the root cause. We shouldn't tweak anything and just stick to Ondrej's scenario where he reproduced the bug. Mikulas > -- > Michal Hocko > SUSE Labs >