Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4329359imm; Wed, 30 May 2018 03:41:33 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI0LL0AjVAmcZCbUnnWBzH50EP51wE/InObsfl+nLhDJI2Ddjgsvl5/TjeY6u+raVeyhy5H X-Received: by 2002:a17:902:2927:: with SMTP id g36-v6mr2271663plb.303.1527676893465; Wed, 30 May 2018 03:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527676893; cv=none; d=google.com; s=arc-20160816; b=nX2pUEZCzDjFtYRTGZ8DLkFzUbhHwL3LgY/SegOnrVecazwxBEXEfdRyD0XoSCPDB0 cQWJlaoH2qmwrovPwaBoKg66X5r89YjQBwP9G/UDYCaKf4ZclxLLZy8INLlyNXO86Dt5 1owyZiC10WgE6G8q5tb8qX+Iaa+7EhXIFHJzUndqRRW8GlwVpNwAd1Vm/VKcEFkDRLQ3 +EnT4Fh5VT2nGh3kGJS8Afy+4/nBSxjquKj5A/telHtdKv+9j/064Uz8VgkfML9HYoed Zu1Fq7Uq8nsMc5QOxsaI02CaGGAZsoLIzuZWS/rMt/YHGX3pQl9Uy9UOXIeN2lCzCnyA DShQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=LKXNzw+dWD2Iz/36/hJhMHml+migFukGUxLy+H/WWsM=; b=ns1jQSb22dhLoXMRy7Kd2xpc7KSi9jK2YuKwe2WZ6PZWJk/S9bkfsNrPC98D2xZHO0 XSKsDqDsvUEdrWe7T70OoaP80iOEMZLM3uoH1DVf7e1e2tJfgMVU4NhWhBDwiqQZo3v+ 6bBFkbUd8y/xn4AFm4N5uCo4YrEN0fyMQmsJ69oYDsPu9B/irFmf5Sk8Xh3nPeb9tLeQ /gAT+NHJsS2U6B0jULPDlMdJeKlSqQS+O1QyBhSrNVNt567xl8ziEstbxc9DcturhlZ1 ABBamvxpKe5T9KQSPROdwoPDzZqlhBRGDq2IkvMZIqye7EWLAOCA5qjqnPy+UiOMtqlJ CJuw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u23-v6si36840567plk.487.2018.05.30.03.41.19; Wed, 30 May 2018 03:41:33 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751655AbeE3Kjr (ORCPT + 99 others); Wed, 30 May 2018 06:39:47 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58900 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750904AbeE3Kjn (ORCPT ); Wed, 30 May 2018 06:39:43 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9885540201A0; Wed, 30 May 2018 10:39:42 +0000 (UTC) Received: from dhcp-12-102.nay.redhat.com (dhcp-12-102.nay.redhat.com [10.66.12.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2227410F1C13; Wed, 30 May 2018 10:39:39 +0000 (UTC) From: Li Wang To: ddstreet@ieee.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Seth Jennings , Huang Ying , Yu Zhao Subject: [PATCH v2] zswap: re-check zswap_is_full after do zswap_shrink Date: Wed, 30 May 2018 18:39:36 +0800 Message-Id: <20180530103936.17812-1-liwang@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 30 May 2018 10:39:42 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 30 May 2018 10:39:42 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'liwang@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The '/sys/../zswap/stored_pages:' keep raising in zswap test with "zswap.max_pool_percent=0" parameter. But theoretically, it should not compress or store pages any more since there is no space in compressed pool. Reproduce steps: 1. Boot kernel with "zswap.enabled=1" 2. Set the max_pool_percent to 0 # echo 0 > /sys/module/zswap/parameters/max_pool_percent 3. Do memory stress test to see if some pages have been compressed # stress --vm 1 --vm-bytes $mem_available"M" --timeout 60s 4. Watching the 'stored_pages' number increasing or not The root cause is: When zswap_max_pool_percent is setting to 0 via kernel parameter, the zswap_is_full() will always return true to do zswap_shrink(). But if the shinking is able to reclain a page successful, then proceeds to compress/store another page, so the value of stored_pages will keep changing. To solve the issue, this patch adds zswap_is_full() check again after zswap_shrink() to make sure it's now under the max_pool_percent, and not to compress/store if reach its limitaion. Signed-off-by: Li Wang Cc: Seth Jennings Cc: Dan Streetman Cc: Huang Ying Cc: Yu Zhao --- mm/zswap.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/zswap.c b/mm/zswap.c index 61a5c41..fd320c3 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1026,6 +1026,15 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, ret = -ENOMEM; goto reject; } + + /* A second zswap_is_full() check after + * zswap_shrink() to make sure it's now + * under the max_pool_percent + */ + if (zswap_is_full()) { + ret = -ENOMEM; + goto reject; + } } /* allocate entry */ -- 2.9.5