From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4C5CC43331 for ; Tue, 12 Nov 2019 20:34:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5E21E206A3 for ; Tue, 12 Nov 2019 20:34:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nIfBYYpx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E21E206A3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E560B6B0005; Tue, 12 Nov 2019 15:34:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E04F46B0007; Tue, 12 Nov 2019 15:34:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1C4A6B0008; Tue, 12 Nov 2019 15:34:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id BC5F46B0005 for ; Tue, 12 Nov 2019 15:34:17 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 80C1E181AC553 for ; Tue, 12 Nov 2019 20:34:17 +0000 (UTC) X-FDA: 76148777754.24.bait79_7caeedb31183d X-HE-Tag: bait79_7caeedb31183d X-Filterd-Recvd-Size: 7525 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Nov 2019 20:34:16 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id j18so3207855wmk.1 for ; Tue, 12 Nov 2019 12:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2HWZCYTuyG/iiIWgucV3SL/wKiXCiXBU5oRVlG/JoY=; b=nIfBYYpx2BPy8Ny2KgYnvusMIUoId7JvzJVuq3x4uT3Ce5l33QonIgnPodqpzgfLnk KwUjAuYZyyC504ndkw8KH/zz1rB8QWChYirmO4TSeQRJ6uW970ne8kuJ64kiTf0mP6tZ 9ZZS1D4Xr29niL4OXMBJhIWVbzrtBr4f5Gfee8T9zAZSGa+P8TpFWxnmeZbIMKgJCZ30 +1tG1fXzk837jA0obwmLORJ95JlTbdlhD4AAy0UG/RNvvw71D1IifjG6atHbmC0HWnxf bjCtQ/mXtEzj3NNFH/q/nufeqZqdwQMDoM+7iXWW0rH2UrGK1DgF9QP5YIrOobEwuu7e uzuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w2HWZCYTuyG/iiIWgucV3SL/wKiXCiXBU5oRVlG/JoY=; b=Q/AJYG6DFVrNLIQ68Fk74PQVbLvB8uSeZ98eEBMJuqTjzs80CzufX4eZaY+jtVtilN tS49oEdMJ8rmrrhF1EFq/Bk6M3W3k9bkhF4ak/oUsHfSDDWT8lkDQaIvG/08jR6dRMTj qIyodSW1k1bobwz0tOrbHLILOP6m3wbsC1WzZly5M8lWMet6Ybvq4TRpAdIicPlxiYxG o5WiNXQ4GBw7r7m9YzlkrMiSJI+NP+cOuR8fahc9DgHzf+wm/e9vvCngDWhNzGl0o4Rc 1Lba2GhJDCm8wh6qFMV8afEdtL0VKYVS+rdaFmfp1CeBlMZemnnTWwaYNOh6JIy3IXjF 7ucw== X-Gm-Message-State: APjAAAXXEJ2U9fjzMx4L9tko1siOjOLEGElWLbzLz8uaJWsZOd5m9GmS cJGZBtjcyGa02cfw9/SoD9IREWVrm2JBeqCnuq/uKQ== X-Google-Smtp-Source: APXvYqzdm1vE6Jn2Mh+18qqFj1F/ivuD1zl/RbxZQOJ5F83vkznTI6U6nlIC66zByigw9coumwdcaYjoCrBFyy6cb7M= X-Received: by 2002:a1c:8055:: with SMTP id b82mr5959862wmd.176.1573590854911; Tue, 12 Nov 2019 12:34:14 -0800 (PST) MIME-Version: 1.0 References: <20191107205334.158354-1-hannes@cmpxchg.org> <20191107205334.158354-4-hannes@cmpxchg.org> <20191112180019.GB178331@cmpxchg.org> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 12 Nov 2019 12:34:03 -0800 Message-ID: Subject: Re: [PATCH 3/3] mm: vmscan: enforce inactive:active ratio at the reclaim root To: Johannes Weiner Cc: Andrew Morton , Andrey Ryabinin , Shakeel Butt , Rik van Riel , Michal Hocko , linux-mm , cgroups mailinglist , LKML , kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000062, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 12, 2019 at 11:13 AM Suren Baghdasaryan wrote: > > On Tue, Nov 12, 2019 at 10:00 AM Johannes Weiner wrote: > > > > On Sun, Nov 10, 2019 at 06:15:50PM -0800, Suren Baghdasaryan wrote: > > > On Thu, Nov 7, 2019 at 12:53 PM Johannes Weiner wrote: > > > > @@ -2758,7 +2775,17 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc) > > > > total_high_wmark += high_wmark_pages(zone); > > > > } > > > > > > > > - sc->file_is_tiny = file + free <= total_high_wmark; > > > > + /* > > > > + * Consider anon: if that's low too, this isn't a > > > > + * runaway file reclaim problem, but rather just > > > > + * extreme pressure. Reclaim as per usual then. > > > > + */ > > > > + anon = node_page_state(pgdat, NR_INACTIVE_ANON); > > > > + > > > > + sc->file_is_tiny = > > > > + file + free <= total_high_wmark && > > > > + !(sc->may_deactivate & DEACTIVATE_ANON) && > > > > + anon >> sc->priority; > > > > > > The name of file_is_tiny flag seems to not correspond with its actual > > > semantics anymore. Maybe rename it into "skip_file"? > > > > I'm not a fan of file_is_tiny, but I also don't like skip_file. IMO > > it's better to have it describe a situation instead of an action, in > > case we later want to take additional action for that situation. > > > > Any other ideas? ;) > > All other ideas still yield verbs (like sc->prefer_anon). Maybe then > add some comment at the file_is_tiny declaration that it represents > not only the fact that the file LRU is too small to reclaim but also > that there are easily reclaimable anon pages? > > > > > > I'm confused about why !(sc->may_deactivate & DEACTIVATE_ANON) should > > > be a prerequisite for skipping file LRU reclaim. IIUC this means we > > > will skip reclaiming from file LRU only when anonymous page > > > deactivation is not allowed. Could you please add a comment explaining > > > this? > > > > The comment above this check tries to explain it: the definition of > > file being "tiny" is dependent on the availability of anon. It's a > > relative comparison. > > > > If file only has a few pages, and anon is easily reclaimable (does not > > require deactivation to reclaim pages), then file is "tiny" and we > > should go after the more plentiful anon pages. > > Your above explanation is much clearer to me than the one in the comment :) > > > > > If anon is under duress, too, this preference doesn't make sense and > > we should just reclaim both lists equally, as per usual. > > > > Note that I'm not introducing this constraint, I'm just changing how > > it's implemented. From the patch: > > > > > > /* > > > > * If the system is almost out of file pages, force-scan anon. > > > > - * But only if there are enough inactive anonymous pages on > > > > - * the LRU. Otherwise, the small LRU gets thrashed. > > > > */ > > > > - if (sc->file_is_tiny && > > > > - !inactive_list_is_low(lruvec, false, sc, false) && > > > > - lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, > > > > - sc->reclaim_idx) >> sc->priority) { > > > > + if (sc->file_is_tiny) { > > > > scan_balance = SCAN_ANON; > > > > goto out; > > > > } > > > > So it's always been checking whether reclaim would deactivate anon, > > and whether inactive_anon has sufficient pages for this priority. > > I didn't realize !inactive_list_is_low(lruvec, false, sc, false) is > effectively the same as !(sc->may_deactivate & DEACTIVATE_ANON) but > after re-reading the patch that makes sense... Except when > force_deactivate==true, in which case shouldn't you consider > NR_ACTIVE_ANON as easily reclaimable too? IOW should it be smth like > this: > > anon = node_page_state(pgdat, NR_INACTIVE_ANON) + > (sc->force_deactivate ? node_page_state(pgdat, NR_ACTIVE_ANON) : 0); > > ? On second thought that proposal would not be correct since deactivation is not the same as reclaim... So the way it is now looks correct. Reviewed-by: Suren Baghdasaryan