Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3902615pxt; Tue, 10 Aug 2021 14:19:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVf/kTdcNOSExt/10EpkKuzLEzkm9p/9zcftlDmlpx4u8ixnORRxyWicqUkwKFHHvs3ixb X-Received: by 2002:a17:906:9ac6:: with SMTP id ah6mr500445ejc.64.1628630343288; Tue, 10 Aug 2021 14:19:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628630343; cv=none; d=google.com; s=arc-20160816; b=jIUCfTn9WKQ5AoQ+hCz6n0K4O1ORmlH56QYzpkLwJTdFd5FxUmPDo8EjJx3pOj0bIV uieh6OZEnR77uoRI5eCoi9oC3z8Dix/NBCldnDVLVmJA2DvPH5BDBaphXFAsurgnKtlk Ft6rIx6IpRd7w2sjAtB5bdSYkNmUMs6dMLR3KOoHxxOKBYOx6VefZ3ulgwPGjg/8YWRm bannkDj9s3VqbgS03KXK0Sq8WEdKTtqX7XhkN4+zWinfTNz3OO3SCzotK+DaiIDwLe/L vUZevvfB8JrwdB+/Z9Zlc9b5NZCCdTettt8zgK46B+QTbDxI4QoPTvB+dHVji0eFjxHy kZxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=jvFV/sPpSnD57KASBlWu5g1n7aznLr5LbeGWzUFeD5E=; b=fhINpCjQl6YDEc1bZBwfnnKgqzAmTcyMXzKg+6aYkkphM5Jd7qhf2+OTAmwgfJscKT PTUgE52vAAlI46UP4iJnM2Uv3jCOD0y3R/2FZhl7GUEP12cbwvtpH3FnEYX8WfRDxjeg lJgNZabIwfRmVK2M7RUad5sbF3NsdpOmrKbuGlNyyxOi/SG1tsvSpgqHi+P1hBbdhd96 y05ehYOK9OqbTgkK9aRUBi9KScLQYN7F/efd3/NuPbReYvHR6i9ikBCqtGHZVa2sWBZZ UYXrRb/9QngENDciXs4Ct9efq0Uj+2clAN9yaZSC/OuYx57e1xDMW0IXdMYOgf+dFE7v TTfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="sBtl8D/E"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cn3si10863811edb.298.2021.08.10.14.18.39; Tue, 10 Aug 2021 14:19:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="sBtl8D/E"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233887AbhHJVQx (ORCPT + 99 others); Tue, 10 Aug 2021 17:16:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232739AbhHJVQs (ORCPT ); Tue, 10 Aug 2021 17:16:48 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AD80C061799 for ; Tue, 10 Aug 2021 14:16:25 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id c24so663409lfi.11 for ; Tue, 10 Aug 2021 14:16:25 -0700 (PDT) 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=jvFV/sPpSnD57KASBlWu5g1n7aznLr5LbeGWzUFeD5E=; b=sBtl8D/ERsUsFcZL/DSOhagTs/HHF9rXwbhthcrPlVwsFYZxjbc2Akh+fMeCQbbRF/ oleiPAHFWd6YEzrc6Qc5kczFgQDdunmQ49ANRJWdKU36tTzoeybe0SsFwSWcTgXbPuf/ xfGmfVUoTFwhmgaB+fGRj9TzNy0X1Ywr21KXcQpArBsu7Ld/pzqzcOx27hytC4gkKI5z PUzBfOvPqiunGRDn/MkRohZOZQS4nwcy44RAoBIeapGzWjrXND1BrSpLKUz5WJdKW8Pq /FEkpC4BetAQBU5lqlx6v3blTMu1WvlycEy3pdYeb/Y9mjFZl1e9h5RPCZTewvuoExqQ B8nQ== 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=jvFV/sPpSnD57KASBlWu5g1n7aznLr5LbeGWzUFeD5E=; b=kEcAOr7JCZ89Vtu48ugawM8N0Wu7wiHU9M/yunKx8MDfuQFYpQwWJbGaEDPyH88WhD de0PONRb9FEg54ZZumWNwfoEVtZxnOJ8DPJIprbHVszNSban+U4b9BlbP5i9fpDO4Eoj 4B4yQ35JRkF1ic3jfnWuUjcWBlgOpjnxopbBRx9b26zc7yU/yN1AejyaAaHlsdlHzSdn 9vMk21pNFOHmVoDj8Gz2R8Cr/QHCNKQUHz42NwoEF9FA+fR6IcKiNRn1r9vumQA/U3ox Omvvnc+SBSTBEt/kEqoIShPFaRGKCMwWshxCb7QKdcRL2ccQqvUXXFu3oFnRXxWgy2As Z4mw== X-Gm-Message-State: AOAM533qqO6TlC88/8Ik37yTqrQyEPh6L+hjbKDB8mjH+mhNdAy9uQM6 Tt8dkJNBq3yBBIu7GgL3BlQxO5GvHVkWIDimUYzbSQ== X-Received: by 2002:a05:6512:10d4:: with SMTP id k20mr12502520lfg.299.1628630183441; Tue, 10 Aug 2021 14:16:23 -0700 (PDT) MIME-Version: 1.0 References: <20210809223740.59009-1-npache@redhat.com> In-Reply-To: From: Shakeel Butt Date: Tue, 10 Aug 2021 14:16:12 -0700 Message-ID: Subject: Re: [PATCH v3] vm_swappiness=0 should still try to avoid swapping anon memory To: Johannes Weiner Cc: Nico Pache , Linux MM , Andrew Morton , LKML , Rafael Aquini , Waiman Long , Michal Hocko , hakavlad@inbox.lv Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johannes, On Tue, Aug 10, 2021 at 8:27 AM Johannes Weiner wrote: > [...] > One thing I think we should do - whether we need more on top or not - > is allowing file reclaim to continue when sc->file_is_tiny. Yes, we > also need anon to meet the watermarks, but it's not clear why we > should stop scanning file pages altogether: it's possible they get us > there 99% of the way, and somebody clearly wanted us to swap as little > as possible to end up in a situation like that, so: > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index eeab6611993c..90dac3dc9903 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2477,7 +2477,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > * If the system is almost out of file pages, force-scan anon. > */ > if (sc->file_is_tiny) { > - scan_balance = SCAN_ANON; > + scan_balance = SCAN_EQUAL; > goto out; > } > Another thing we should do is to re-evaluate the sc->file_is_tiny condition. Currently it is: 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; First convert node_page_state() usage to lruvec_page_state() for common source of truth. Second, in the commit b91ac374346b (sc->may_deactivate & DEACTIVATE_ANON) implies inactive_is_low(LRU_INACTIVE_ANON) but commit 170b04b7ae49 changed that. Was that intended? Third, the comment above this code says "Consider anon" but it is only considering inactive anon. Do we need to change the comment or the check?