Received: by 10.223.176.5 with SMTP id f5csp2427552wra; Mon, 5 Feb 2018 04:01:53 -0800 (PST) X-Google-Smtp-Source: AH8x227rB8Oj/mnhKxyQa0eZmi+TCXMxkFYOWBiQUsYNFB7ss4ri1T3dp2VpHVBglc9SQ9SOlp95 X-Received: by 2002:a17:902:7b81:: with SMTP id w1-v6mr20373495pll.295.1517832113801; Mon, 05 Feb 2018 04:01:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517832113; cv=none; d=google.com; s=arc-20160816; b=UclfDyduTI6heGoADCTTu66oDHmmubYXRa1wfJSngE1iSnzhl4eZbNs673Q8BksUqP takEQWqcK2QkklgcsESbpwiV092upZpHaQol6KcFwdxc+FXiEnRuhza2XNL2BKtYrq27 tBKfbBNf253rQaWrYSBLgkCX6831Jk5w2eKvg+jXWTtByJz0lJf9Kaui0oF0qPJOgBmP aXIUf2XJKplWOscOJ6Ygamj2dTtakYDX9IDlOm7+GtisqYblFqhhY0ro5pzT50H+KI45 4sUIGLeu2xUSlA3MiLp9efuYhI0wI931Ov/wa4OOyYmmZwVPEgWwvtQqA9ldy/lFHpyo PX5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=AHhYyc7KOmeUTIqCtjqLA29pE41966Q6ALM8gT8IuiM=; b=tzwZy49WU1JpjAQHDxPjQe+QKsXtHDWufXnWyRQnxUeFgQ4EH730LfnZaxgZhcehWz Z7XwJQpuovtvWii5BxZK8UUEAzCRJjg7S46U+D9ge7CwTLsbq4kY3ol7fSjXibiodaX3 l4vBBAfRSL161rFkd/xvmGSpb+zkih9UQRURejvKz6LXLmIYEf7vMmig29fNsx5as4HT frHLa8tfvKQLSSEhr9marsgZGiZrjulgBMqjcRfBGSOh8/1CjJG/sF/8CaBaVZdyJJ9H TaNaei+N2wbmWqHPSna01GmxrChjgk7ALv9WQolsEV/9Rzg0KPg9UC3OEQ2QdeJgWkit bxXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 70-v6si4290846ple.246.2018.02.05.04.01.37; Mon, 05 Feb 2018 04:01:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752855AbeBEMBG (ORCPT + 99 others); Mon, 5 Feb 2018 07:01:06 -0500 Received: from mga07.intel.com ([134.134.136.100]:44119 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752260AbeBEMBB (ORCPT ); Mon, 5 Feb 2018 07:01:01 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2018 04:01:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,464,1511856000"; d="scan'208";a="24926821" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.13.10]) by FMSMGA003.fm.intel.com with ESMTP; 05 Feb 2018 04:00:58 -0800 From: "Huang\, Ying" To: Sergey Senozhatsky Cc: huang ying , Andrew Morton , "Michal Hocko" , Vlastimil Babka , "Sergey Senozhatsky" , Minchan Kim , Seth Jennings , Dan Streetman , "Kirill A . Shutemov" , , LKML Subject: Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash) References: <20180130114841.aa2d3bd99526c03c6a5b5810@linux-foundation.org> <20180203013455.GA739@jagdpanzerIV> <20180205013758.GA648@jagdpanzerIV> Date: Mon, 05 Feb 2018 20:00:57 +0800 In-Reply-To: <20180205013758.GA648@jagdpanzerIV> (Sergey Senozhatsky's message of "Mon, 5 Feb 2018 10:37:58 +0900") Message-ID: <87d11j4pdy.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sergey Senozhatsky writes: > Hi, > > On (02/04/18 22:21), huang ying wrote: > [..] >> >> After disabling zswap no crashes at all. >> >> >> >> /etc/systemd/swap.conf >> >> zswap_enabled=1 >> >> zswap_compressor=lz4 # lzo lz4 >> >> zswap_max_pool_percent=25 # 1-99 >> >> zswap_zpool=zbud # zbud z3fold >> > > [..] >> Can you give me some detailed steps to reproduce this? Like the >> kernel configuration file, swap configuration, etc. Any kernel >> WARNING during testing? Can you reproduce this with a real swap >> device instead of zswap? > > No warnings (at least no warnings with my .config). Tested it only with > zram based swap (I'm running swap-less x86 systems, so zram is the easiest > way). It seems it's THP + frontswap that makes things unstable, rather > than THP + swap. > > Kernel zswap boot params: > zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=10 zswap.zpool=zbud > > Then I add a 4G zram swap and run a silly memory hogger. I don't think > you'll have any problems reproducing it, but just in case I attached my > .config I have successfully reproduced the issue and find the problem. The following patch fix the issue for me, can you try it? Best Regards, Huang, Ying ---------------------------------8<------------------------------- From 4c52d531680f91572ebc6f4525a018e32a934ef0 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Mon, 5 Feb 2018 19:27:43 +0800 Subject: [PATCH] fontswap thp fix --- mm/page_io.c | 2 +- mm/vmscan.c | 16 +++++++++++++--- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/mm/page_io.c b/mm/page_io.c index b41cf9644585..6dca817ae7a0 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc) unlock_page(page); goto out; } - if (frontswap_store(page) == 0) { + if (!PageTransHuge(page) && frontswap_store(page) == 0) { set_page_writeback(page); unlock_page(page); end_page_writeback(page); diff --git a/mm/vmscan.c b/mm/vmscan.c index bee53495a829..d1c1e00b08bb 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -55,6 +55,7 @@ #include #include +#include #include "internal.h" @@ -1063,14 +1064,23 @@ static unsigned long shrink_page_list(struct list_head *page_list, /* cannot split THP, skip it */ if (!can_split_huge_page(page, NULL)) goto activate_locked; + /* + * Split THP if frontswap enabled, + * because it cannot process THP + */ + if (frontswap_enabled()) { + if (split_huge_page_to_list( + page, page_list)) + goto activate_locked; + } /* * Split pages without a PMD map right * away. Chances are some or all of the * tail pages can be freed without IO. */ - if (!compound_mapcount(page) && - split_huge_page_to_list(page, - page_list)) + else if (!compound_mapcount(page) && + split_huge_page_to_list(page, + page_list)) goto activate_locked; } if (!add_to_swap(page)) { -- 2.15.1