From patchwork Wed May 30 02:57:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Li Wang X-Patchwork-Id: 10437539 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 49C4860116 for ; Wed, 30 May 2018 02:57:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 262EC28567 for ; Wed, 30 May 2018 02:57:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 16253285D9; Wed, 30 May 2018 02:57:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D2F1328567 for ; Wed, 30 May 2018 02:57:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE5BA6B0003; Tue, 29 May 2018 22:57:29 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id A6C4B6B0005; Tue, 29 May 2018 22:57:29 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 935E26B0007; Tue, 29 May 2018 22:57:29 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) by kanga.kvack.org (Postfix) with ESMTP id 5802B6B0003 for ; Tue, 29 May 2018 22:57:29 -0400 (EDT) Received: by mail-ua0-f198.google.com with SMTP id u23-v6so11004271ual.4 for ; Tue, 29 May 2018 19:57:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:mime-version :in-reply-to:references:from:date:message-id:subject:to:cc; bh=18f7IFKozbUMlNavwWr0JSImmq8+f4ohOxix4pwoT/g=; b=pl3EcXjQVTuGmYIpzVupSqbpvJVPVEDVGhaCxew48oWl4pc8S7Nsb+QtRQ8niXWY12 Tc50HIWHERCXkcDDF9QUMS+fNat9Axw3kVFb5T+FSH1sFMqYAmFUoMNGvYTDle8bik2d AONSpaMzBcAmCSiee4zH8fvLb/6wMNjc7yZrqEkh/cneNwzT3K5cux/j+sImU/Ls9Gke JoISnIwCxcDuWEpew7yCLwPMUezI7WVOsECI1FtBcD9pS2pnUArrXCXoZqtwxf0dk+pZ AIrGz5Yt1895CQKI01djKSyGq+mgmUKMonj+Cb4VDh5DLh2D6OZLZFv65Ct10E5Hymtp 8b+Q== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of liwan@redhat.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=liwan@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: ALKqPwfgoW7fVhkf0pN9ATck6EjI/l3JDv+VtrnIgq9sS1RFZa6u9FNm HdN9wCjNb/xyzwogfk9+XRhYkqmQuwyTvB5KoP5qtURKGA7DcCvi78DmzOhgF8fRet3PC+Bh1NW J9scTED/pBbZTOnbMxRPSrg4henP7Em8pL2DGWB7aPWiJjYPO+QCu58UJ7CTyKOICBjQJcxvNqU ohOyZfprtb58kiDCeyve8p0t+qyA1uiGnX43g6h5N7krGZXLZBs/BqLmJA8MhQATuSvC/lcykN4 XWfj6Q1zrJp+h5XDuX8YRAFUeiL9abb5O06roOkMRFbJz06NbvfU8kt7fm99N0c7hyiBlVDVTev 9aD4nks1jK35IaK9zAECvZ04Rx26Tj0Gcd6xdcu5FCWhIOaS74Q8WhDevPGkH7dKKxd/TQxtMp4 F X-Received: by 2002:a1f:e47:: with SMTP id 68-v6mr477054vko.126.1527649048964; Tue, 29 May 2018 19:57:28 -0700 (PDT) X-Received: by 2002:a1f:e47:: with SMTP id 68-v6mr477023vko.126.1527649047841; Tue, 29 May 2018 19:57:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527649047; cv=none; d=google.com; s=arc-20160816; b=MreyGto+3O1s9y5NUivETDv/0r7UAMj6/fi/Q9mPPlvF7asHTcGr9/qOd7inEOYUUn Ogi8lb3rnGW3QmZ4kmjChO6ANXaBOnwlS4pHKuIONOmqKZmWFqAKfr09l1/QJCoijDSK w5mLa9WgxyLFYjhHDtIsvv1Wgp1kZHBn1bUYGnoGb8tMsh8ajC/eUKGBOy8cbInJfh/F 4u3riW1I+vgtEIXd5DzlPPcrI0xZDLz1OYK1WjSV2/ntgsXPcnlaAvzcklz1NAh/QFKY STOrBFGAa6segPi40kDWDBEkxHKCnSMQcfUX5x37WIRIl+Aff/OKsrOu5uUDwAg37/Li 8kIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:arc-authentication-results; bh=18f7IFKozbUMlNavwWr0JSImmq8+f4ohOxix4pwoT/g=; b=ycWpZT3kc1Kc/6sb/76o1PR/PtxaG9HMy0lTcqRzc9nwpR7ZdSaTiHf4QBAfEvw2l0 FhqwyFu9M2uOpXKEOgYQ2OuL/xWpoW9eTR3+xBZV4JQ6eJnWygwlRpEPSigUIQl8NX24 qFOWQ5UY1WhYe9DFBxlWqVNPL6iuItfA3jU/otAERWqWvdRQYR9atS5pVhJu69VXUlZM eKcoK7Z2wB8wdmvRWAwU286CQfVEEaFaUMJ/NF+JNMMDh6WHCwxxMOtYm2D9IKincxgq Jd51l9BWd02eavB70Xfo5xflRHqRCK2324nhkF98zOng9bG4lLdUZAV8hl+fDcj9UqbZ 3vyg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of liwan@redhat.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=liwan@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id j62-v6sor3288488vkd.287.2018.05.29.19.57.27 for (Google Transport Security); Tue, 29 May 2018 19:57:27 -0700 (PDT) Received-SPF: pass (google.com: domain of liwan@redhat.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; spf=pass (google.com: domain of liwan@redhat.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=liwan@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Google-Smtp-Source: ADUXVKJrq6DD2TPmdAe5zWWWROtQfmKmoX3jUd68+h+47t8pPoFY+GOuTnySmw/s2WEuknTk6XUefgj1FhgD1e7b+ys= X-Received: by 2002:a1f:f0a:: with SMTP id 10-v6mr468429vkp.178.1527649047512; Tue, 29 May 2018 19:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:4b90:0:0:0:0:0 with HTTP; Tue, 29 May 2018 19:57:26 -0700 (PDT) In-Reply-To: References: <20180524095752.17770-1-liwang@redhat.com> From: Li Wang Date: Wed, 30 May 2018 10:57:26 +0800 Message-ID: Subject: Re: [PATCH RFC] zswap: reject to compress/store page if zswap_max_pool_percent is 0 To: Dan Streetman Cc: Linux-MM , linux-kernel , Seth Jennings , Huang Ying , Yu Zhao X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Hi Dan, On Wed, May 30, 2018 at 5:14 AM, Dan Streetman wrote: > On Thu, May 24, 2018 at 5:57 AM, Li Wang wrote: > > 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 for > > compressed pool. > > > > Reproduce steps: > > > > 1. Boot kernel with "zswap.enabled=1 zswap.max_pool_percent=17" > > 2. Set the max_pool_percent to 0 > > # echo 0 > /sys/module/zswap/parameters/max_pool_percent > > Confirm this parameter works fine > > # cat /sys/kernel/debug/zswap/pool_total_size > > 0 > > 3. Do memory stress test to see if some pages have been compressed > > # stress --vm 1 --vm-bytes $mem_available"M" --timeout 60s > > Watching the 'stored_pages' numbers increasing or not > > > > The root cause is: > > > > When the zswap_max_pool_percent is set to 0 via kernel parameter, the > zswap_is_full() > > will always return true to shrink the pool size by zswap_shrink(). If > the pool size > > has been shrinked a little success, zswap will do compress/store pages > again. Then we > > get fails on that as above. > > special casing 0% doesn't make a lot of sense to me, and I'm not > entirely sure what exactly you are trying to fix here. > ​Sorry for that confusing, I am a pretty new to zswap. To specify 0 to max_pool_percent is purpose to verify if zswap stopping work when there is no space in compressed pool.​ Another consideration from me is: [Method A] So, which one do you think is better, A or B? --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1021,7 +1021,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset, /* reclaim space if needed */ if (zswap_is_full()) { zswap_pool_limit_hit++; - if (zswap_shrink()) { + if (!zswap_max_pool_percent || zswap_shrink()) { zswap_reject_reclaim_fail++; ret = -ENOMEM; goto reject; This make sure the compressed pool is enough to do zswap_shrink(). > > however, zswap does currently do a zswap_is_full() check, and then if > it's able to reclaim a page happily proceeds to store another page, > without re-checking zswap_is_full(). If you're trying to fix that, > then I would ack a patch that adds a second zswap_is_full() check > after zswap_shrink() to make sure it's now under the max_pool_percent > (or somehow otherwise fixes that behavior). > > ​Ok, it sounds like can also fix the issue. The changes maybe like: [Method B] --- 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; + } }