Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp991450imu; Wed, 9 Jan 2019 09:39:36 -0800 (PST) X-Google-Smtp-Source: ALg8bN5cRp0OZLFTmA3xQAXkf8ajF05LXX6xadTp7Ju04GJmK9dnqcQYjR9GaR1CgCZR9aXzO8z0 X-Received: by 2002:a65:51ca:: with SMTP id i10mr6037379pgq.371.1547055576373; Wed, 09 Jan 2019 09:39:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547055576; cv=none; d=google.com; s=arc-20160816; b=wEikIgoIwmwPod467qPpkNun5FC4Ch560y5QmD7jU0IEftARrVth7hCIXsCMuTZL0R k4iS46NmrgevAGL13J4/hidgXtOziPYMUmdMEb7Tjp77sInx9ZFI+BXlmxXnh7G8LnV+ bsM9tdLN3QxxQc1+EoC+5fgJGtam3BPo9jFWdGUBkKsgjFGbt9wkwVUfnttHVAj7tdi5 5Yx7HsdfZzZ7INpAstBy5N9pI3V2OOp3XGWb0L7D/hRQwIrgrPb86LbRcYFJaBdIoC1r fG1oBvegZTCpu1hJkWBvUXcG1pCxhRMRam2pdSJpiyIyG/CpK5RCUydMA6jD9qvsFX7G qDuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=00fTbS3NCEslFjaEEkgF4Su3Ks4m2l6BsBiP5Boa2l0=; b=GBtXcd77acacWLWmkCQs/c3h2FwuwDPvHRAYFCxuN0qcW+47tsu435T5JIU+FYAoU2 1ZEAfKfayjsE/Tz4KJ2CojeAv1UCGOqaFk/79JZFQsIqsJmeTPMwY2Xqh08dKrqMv/lO ChbU66rgeVCekD0/OcL1qa6qgZfy+gMfLql3gi7LLTVVscZxJQhxCq0YNyQ7salUiN+j Ukra23HAZt2/unDb8R3PdFkPthQM/aP46XEjMyvfpu0rTRN69/uSkijpJLbeKdv2cbRv CyXibEyGHYrHt1OBkJ/a2LjUhAOYUvWHDErGsBp0T4i46ESZXX2nS/gyiuNnqgBNWlW1 Xzsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=PCmVpAsT; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u11si8222833plq.287.2019.01.09.09.39.19; Wed, 09 Jan 2019 09:39:36 -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=@google.com header.s=20161025 header.b=PCmVpAsT; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727007AbfAIRiF (ORCPT + 99 others); Wed, 9 Jan 2019 12:38:05 -0500 Received: from mail-yw1-f66.google.com ([209.85.161.66]:35451 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726629AbfAIRiF (ORCPT ); Wed, 9 Jan 2019 12:38:05 -0500 Received: by mail-yw1-f66.google.com with SMTP id h32so3288475ywk.2 for ; Wed, 09 Jan 2019 09:38:04 -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=00fTbS3NCEslFjaEEkgF4Su3Ks4m2l6BsBiP5Boa2l0=; b=PCmVpAsT+zT4tvr3NYlV7WkaIrd9SDdr0dOP0bDElU4rjd0kgShYNDaJsWYaMATLVM mWhX3zIqkfy2vURZrofhnbYPUt78gWs35gBHEvEV/9o9/OUJZJ9hnpMhAtp9WT2+SGPG yQiUiwrRl9dKDm5KkL+pKXUNKQxGIuQ61Mp45bV9a8BteD03F8ouB8lIpATOHSA7RUTQ zD7kfiigA5E6jUpgnrSJDgZzUA5EY8uFejYCcJ4Jgq1/F5uHMCMzKSwCtfwikHGl/lek JqSG7s8ChVg/+6DrZr90++om9d8bky1bZG7kS58De6g0V4RvyLG9gr+KlWn60dr4rZu2 DlzQ== 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=00fTbS3NCEslFjaEEkgF4Su3Ks4m2l6BsBiP5Boa2l0=; b=ExfzdczWJkZ2XRXnqaSQjCejpz8LYD+/8keBvXZfkmu56fzJiS0TWbLXb0xWwSphmd 3zvUap0UNNudTycFEJquJ1bvWl+9MBoGhgicWTYxyGtStZZFW1WjQp9elv7Nca66HyrC W/5LB47MTZYpRs+IBTcwVlosYevnqkEK1hFZO3R8+rLPvkjZD3xQ8LoWTEwXj4A/tjrT gfHQlThz396mgUfaeAsAYBkG7RT5J2rZnIhgKP8cQOW4RGChH55urvk+7+dXkyXNZJkr UaSvLe2LpQUsBMqfTs8lKy7zptBvJZxsO8Dm6DJNeDdUVvJay7wrtGpJTDic0NX3jfrd /1KA== X-Gm-Message-State: AJcUukeIH1VzDs3gtIKkilXlFCwKAXYsnmVoPgknrlfWex9j0pqLmN9x ipPjkxJUCLMvpfhUCLj4FC4OcgV90fl0o4wvoX7/wA== X-Received: by 2002:a81:60c4:: with SMTP id u187mr6514817ywb.345.1547055483981; Wed, 09 Jan 2019 09:38:03 -0800 (PST) MIME-Version: 1.0 References: <154703479840.32690.6504699919905946726.stgit@localhost.localdomain> In-Reply-To: <154703479840.32690.6504699919905946726.stgit@localhost.localdomain> From: Shakeel Butt Date: Wed, 9 Jan 2019 09:37:52 -0800 Message-ID: Subject: Re: [PATCH RFC 0/3] mm: Reduce IO by improving algorithm of memcg pagecache pages eviction To: Kirill Tkhai Cc: Andrew Morton , Johannes Weiner , josef@toxicpanda.com, Jan Kara , Hugh Dickins , "Darrick J. Wong" , Michal Hocko , Andrey Ryabinin , Roman Gushchin , Mel Gorman , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kirill, On Wed, Jan 9, 2019 at 4:20 AM Kirill Tkhai wrote: > > On nodes without memory overcommit, it's common a situation, > when memcg exceeds its limit and pages from pagecache are > shrinked on reclaim, while node has a lot of free memory. > Further access to the pages requires real device IO, while > IO causes time delays, worse powerusage, worse throughput > for other users of the device, etc. > > Cleancache is not a good solution for this problem, since > it implies copying of page on every cleancache_put_page() > and cleancache_get_page(). Also, it requires introduction > of internal per-cleancache_ops data structures to manage > cached pages and their inodes relationships, which again > introduces overhead. > > This patchset introduces another solution. It introduces > a new scheme for evicting memcg pages: > > 1)__remove_mapping() uncharges unmapped page memcg > and leaves page in pagecache on memcg reclaim; > > 2)putback_lru_page() places page into root_mem_cgroup > list, since its memcg is NULL. Page may be evicted > on global reclaim (and this will be easily, as > page is not mapped, so shrinker will shrink it > with 100% probability of success); > > 3)pagecache_get_page() charges page into memcg of > a task, which takes it first. > From what I understand from the proposal, on memcg reclaim, the file pages are uncharged but kept in the memory and if they are accessed again (either through mmap or syscall), they will be charged again but to the requesting memcg. Also it is assumed that the global reclaim of such uncharged file pages is very fast and deterministic. Is that right? Shakeel > Below is small test, which shows profit of the patchset. > > Create memcg with limit 20M (exact value does not matter much): > $ mkdir /sys/fs/cgroup/memory/ct > $ echo 20M > /sys/fs/cgroup/memory/ct/memory.limit_in_bytes > $ echo $$ > /sys/fs/cgroup/memory/ct/tasks > > Then twice read 1GB file: > $ time cat file_1gb > /dev/null > > Before (2 iterations): > 1)0.01user 0.82system 0:11.16elapsed 7%CPU > 2)0.01user 0.91system 0:11.16elapsed 8%CPU > > After (2 iterations): > 1)0.01user 0.57system 0:11.31elapsed 5%CPU > 2)0.00user 0.28system 0:00.28elapsed 100%CPU > > With the patch set applied, we have file pages are cached > during the second read, so the result is 39 times faster. > > This may be useful for slow disks, NFS, nodes without > overcommit by memory, in case of two memcg access the same > files, etc. > > --- > > Kirill Tkhai (3): > mm: Uncharge and keep page in pagecache on memcg reclaim > mm: Recharge page memcg on first get from pagecache > mm: Pass FGP_NOWAIT in generic_file_buffered_read and enable ext4 > > > fs/ext4/inode.c | 1 + > include/linux/pagemap.h | 1 + > mm/filemap.c | 38 ++++++++++++++++++++++++++++++++++++-- > mm/vmscan.c | 22 ++++++++++++++++++---- > 4 files changed, 56 insertions(+), 6 deletions(-) > > -- > Signed-off-by: Kirill Tkhai