From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751628AbdJSDTM (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Oct 2017 23:19:12 -0400
Received: from mail-pg0-f68.google.com ([74.125.83.68]:44534 "EHLO
        mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751592AbdJSDTK (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Oct 2017 23:19:10 -0400
X-Google-Smtp-Source: ABhQp+QrPWOJD2TUjcMJwuNCypYEaaplruWzJGwtogxLSX1HN4gF1G3QKXiUofLq2TK2Sj4VhUxPaw==
Date: Thu, 19 Oct 2017 14:18:59 +1100
From: Balbir Singh <bsingharora@gmail.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>, Minchan Kim <minchan@kernel.org>,
        Yisheng Xie <xieyisheng1@huawei.com>, Ingo Molnar <mingo@kernel.org>,
        Greg Thelen <gthelen@google.com>, Hugh Dickins <hughd@google.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: mlock: remove lru_add_drain_all()
Message-ID: <20171019141859.4c17f813@MiWiFi-R3-srv>
In-Reply-To: <20171018231730.42754-1-shakeelb@google.com>
References: <20171018231730.42754-1-shakeelb@google.com>
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 18 Oct 2017 16:17:30 -0700
Shakeel Butt <shakeelb@google.com> wrote:

> Recently we have observed high latency in mlock() in our generic
> library and noticed that users have started using tmpfs files even
> without swap and the latency was due to expensive remote LRU cache
> draining.
> 
> Is lru_add_drain_all() required by mlock()? The answer is no and the
> reason it is still in mlock() is to rapidly move mlocked pages to
> unevictable LRU. Without lru_add_drain_all() the mlocked pages which
> were on pagevec at mlock() time will be moved to evictable LRUs but
> will eventually be moved back to unevictable LRU by reclaim. So, we
> can safely remove lru_add_drain_all() from mlock(). Also there is no
> need for local lru_add_drain() as it will be called deep inside
> __mm_populate() (in follow_page_pte()).
> 
> Signed-off-by: Shakeel Butt <shakeelb@google.com>
> ---

Does this perturb statistics around LRU pages in cgroups and meminfo
about where the pages actually belong?

Balbir Singh.