Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp1747863imc; Fri, 22 Feb 2019 10:23:49 -0800 (PST) X-Google-Smtp-Source: AHgI3IZu3Ok2WYCegSj31cegRJpkppKeee8TwZvNRvI8qAFX9EIeGLE5KwmnDXo3nwZrjKN0DUMr X-Received: by 2002:a63:c042:: with SMTP id z2mr5210392pgi.307.1550859829367; Fri, 22 Feb 2019 10:23:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550859829; cv=none; d=google.com; s=arc-20160816; b=PSPwXofkFFglocyqf2jfeyzrX3PYKdZShEta7562cyfl3sheUyga9vsesjZr2b37jD L3Tbdk17n5WwDfof9KtFUy4Z5Q2CmXlEADFid8kcm7jj0z21jjW3R/eraRUIbyo1maxF 5F9pgO7jaWtSblHPAfSUQI3f897EPZlF74nZV1LQXFwqJb9boRSaNxAyUIKpvKiITxL3 q/eW9NAapqtlx45ff+WDUkRCKNDywaGVE9EAh3UdP62lnbojEnjBG8PVki1yR3yTJ5T4 Xojwt283OE7C0mIDc4uaQYs+nExyMcOqmARoRaLWd706AIjYJwTS98C80Mmfo5mYgpjk LKdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=/1iRUWXUez0vQmzuA6ScUoUTtthAjz8oJPlMkoBcgCo=; b=SZiWGjSiZYfe/ZtM7vfeWrBvI1Yd5vKVVOY+qOt3u+i4MnXcQTDfYjWvU9jNbStvjD ClN7QikB55FodxUDzpGtJnDATV+NnpgptofD3C7FMHwM6i64qdXDEmXAsEgK4SD5rRMD fXI33BsCg0Wm6boVuTTVDyuNuax67mRP4piaSpNQMM8jPWsHux2sVGO6cobDqg8cjK69 25DwfhLkzGDitxbBLTPslccJdwu5LhC82pCpBWhGJiV2cQPo7OpFYVzIhOEtEY/J6uYI FsQbHCu2X7kSITaS/28UjdpKa6u9yNcbqaO+Ewju/L/opbIIooyWkP3Hp0W8QZNVgxm4 c7dQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=b267o0z6; 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=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s2si1830293pfm.289.2019.02.22.10.23.33; Fri, 22 Feb 2019 10:23:49 -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; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=b267o0z6; 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=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726972AbfBVSWx (ORCPT + 99 others); Fri, 22 Feb 2019 13:22:53 -0500 Received: from mail-yw1-f68.google.com ([209.85.161.68]:44992 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbfBVSWw (ORCPT ); Fri, 22 Feb 2019 13:22:52 -0500 Received: by mail-yw1-f68.google.com with SMTP id x21so1169551ywx.11 for ; Fri, 22 Feb 2019 10:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/1iRUWXUez0vQmzuA6ScUoUTtthAjz8oJPlMkoBcgCo=; b=b267o0z6qksczZ6tdLwpa3oMpBghC7VNreLZWEEy860EODd2+i/QjS4nWyY/ryDODy a5G8IZp8wvWZSWhb7LkpNdYs8nPu3EkOMlFPeqdRA++vk8m1TL08DMGGvBd6ZgP9Rpca 6uBxZmBrK0rW0yNb2CK8KhQs3FNIRWoyUwECysD6/T4pXlFsnJTz6wcq8L5GoBjcEu7I RoN+qZym0HIiSVeQtM0NP3F50AmXJmjmn609rEXS5ph0WTJkbe8D0l5DG8rP0GWSIYfU 3F7gjmpDG5rf9TUjQfVAHmOLn1pXQ6iCoXcwdNB7bCIG/6Kbwc3dgPl6o4khb+jF1Z84 fbSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/1iRUWXUez0vQmzuA6ScUoUTtthAjz8oJPlMkoBcgCo=; b=UWxvRwC9NZrF2YHGfbgNlRS+Oyqre35FK20tjRhrPil9HFO1AoE+Sryp5D2dXQ1ZDR DvBDKt7gL09WWSIBtvP8R35kArqVZShS1AZZfdyItIBwdVrqTfhboLJ+hWTtWN7YJNV/ OU/vYpkzxUGykcCZ+zrA8jfuxvGOkCS+BDERumPKa7k9w8J9mFRNipOT0G0vTgeqoiVB uHuFE2PSp3EdhNSKmCl6Bt+obiR0ZjDA+5tyAZHKQ5TFr2i84OAdiOkCQUCm51n7r7zF fIrF5NB+DdCNsswwx4BPxU9sGYfTAIrKysfT6TCw/QEgUDgEp9quD7qwvvtWrw4rBOTk Jv7w== X-Gm-Message-State: AHQUAuZWkpJ0MQQaBjfu6wqC7IwGvzSrjc8QjL2kyJ9XFwpkMOocMcFl gEg7r+lm47ATbRDJLaM7yzPqew== X-Received: by 2002:a81:36ca:: with SMTP id d193mr4536619ywa.388.1550859771539; Fri, 22 Feb 2019 10:22:51 -0800 (PST) Received: from localhost ([2620:10d:c091:200::1:cd3d]) by smtp.gmail.com with ESMTPSA id c124sm683685ywe.12.2019.02.22.10.22.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Feb 2019 10:22:50 -0800 (PST) Date: Fri, 22 Feb 2019 13:22:49 -0500 From: Johannes Weiner To: Andrey Ryabinin Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Vlastimil Babka , Rik van Riel , Mel Gorman Subject: Re: [PATCH 5/5] mm/vmscan: don't forcely shrink active anon lru list Message-ID: <20190222182249.GC15440@cmpxchg.org> References: <20190222174337.26390-1-aryabinin@virtuozzo.com> <20190222174337.26390-5-aryabinin@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222174337.26390-5-aryabinin@virtuozzo.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 22, 2019 at 08:43:37PM +0300, Andrey Ryabinin wrote: > shrink_node_memcg() always forcely shrink active anon list. > This doesn't seem like correct behavior. If system/memcg has no swap, it's > absolutely pointless to rebalance anon lru lists. > And in case we did scan the active anon list above, it's unclear why would > we need this additional force scan. If there are cases when we want more > aggressive scan of the anon lru we should just change the scan target > in get_scan_count() (and better explain such cases in the comments). > > Remove this force shrink and let get_scan_count() to decide how > much of active anon we want to shrink. This change breaks the anon pre-aging. The idea behind this is that the VM maintains a small batch of anon reclaim candidates with recent access information. On every reclaim, even when we just trim cache, which is the most common reclaim mode, but also when we just swapped out some pages and shrunk the inactive anon list, at the end of it we make sure that the list of potential anon candidates is refilled for the next reclaim cycle. The comments for this are above inactive_list_is_low() and the age_active_anon() call from kswapd. Re: no swap, you are correct. We should gate that rebalancing on total_swap_pages, just like age_active_anon() does.