Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp978887ybi; Wed, 3 Jul 2019 07:31:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqzVYYAsrG4GyF3wNcs9DjIufoTIYM0brZHuY6qDngOm697H2dO5GIEmb/boKtkritITfXWt X-Received: by 2002:a17:90a:8d0d:: with SMTP id c13mr12647337pjo.137.1562164298340; Wed, 03 Jul 2019 07:31:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562164298; cv=none; d=google.com; s=arc-20160816; b=iGtalj8CjNxozdwKwR0hDn1fa7MkN509RGiJqaU9xj7hWMMjNn21EpUhw/OfF7brPz 8FVkOBgsx1ECaw1iNph/hE8ZLdtbAbyzEYFvhH+KY/7+jIv6k1m9GX7XlfJmlsiO3oZz DhkTHiljJuKxsCMFrQmVd3GQJkAc0CP0RcW4UHrFlSbeu6eiOSsYNqwZMmi3GPbNBei1 D3vj7TT53pEviBtnZcMllHYTSOOeFmc+WKx5pTgFmzcZTIRsbHkiWc8Eox+uRu53YQA+ doDgdHisGHQX8Tt2JGp6qyNIVt7dsoT7WZCF0m2yfk7A34NXd4r18gRq3YBxdYDabXXC e4Ug== 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; bh=aymayfheh4NTbUMjrZGECjsvaS5WW1lfzjYtxfajXyo=; b=C2PdReCkbt4YIYS37kCf6bgb2KIj5kky39iNILPXauz0sOtZpqucb7ELy0Myx2ckxp h8ZfP2zOYQDwKE3FwTLyNw3UghWul8mjZmgbm8ntqNEVB9dqQR1Ky7gGWQf9GoN+tsnc 9UrDZ7pVDooxwMGtw/0fUn3XHuP3QZKxRHr1Dn9+O+rITjXyNUPfRgVQcBuKA8AR4IOS FjUNkaC0sW5mhBUYsrnrs0eZqM3aRPqoYlVKoORiFyM6d939ySQmkeC9fUL7zBENSErk FfhpB8T4Crm5quo04TDAic8wvwdwciRO3PGgwnlt4UIV4P1YUyY1L3kMqxavLL+7CuFU n8vA== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h33si2092728pje.95.2019.07.03.07.31.22; Wed, 03 Jul 2019 07:31:38 -0700 (PDT) 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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726966AbfGCObA (ORCPT + 99 others); Wed, 3 Jul 2019 10:31:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:47884 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725830AbfGCObA (ORCPT ); Wed, 3 Jul 2019 10:31:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F3C80AD76; Wed, 3 Jul 2019 14:30:58 +0000 (UTC) Date: Wed, 3 Jul 2019 16:30:57 +0200 From: Michal Hocko To: Kuo-Hsin Yang Cc: Andrew Morton , Johannes Weiner , Minchan Kim , Sonny Rao , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH] mm: vmscan: scan anonymous pages on file refaults Message-ID: <20190703143057.GQ978@dhcp22.suse.cz> References: <20190628111627.GA107040@google.com> <20190701081038.GA83398@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190701081038.GA83398@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 01-07-19 16:10:38, Kuo-Hsin Yang wrote: > When file refaults are detected and there are many inactive file pages, > the system never reclaim anonymous pages, the file pages are dropped > aggressively when there are still a lot of cold anonymous pages and > system thrashes. This issue impacts the performance of applications > with large executable, e.g. chrome. > > With this patch, when file refault is detected, inactive_list_is_low() > always returns true for file pages in get_scan_count() to enable > scanning anonymous pages. > > The problem can be reproduced by the following test program. > > ---8<--- > void fallocate_file(const char *filename, off_t size) > { > struct stat st; > int fd; > > if (!stat(filename, &st) && st.st_size >= size) > return; > > fd = open(filename, O_WRONLY | O_CREAT, 0600); > if (fd < 0) { > perror("create file"); > exit(1); > } > if (posix_fallocate(fd, 0, size)) { > perror("fallocate"); > exit(1); > } > close(fd); > } > > long *alloc_anon(long size) > { > long *start = malloc(size); > memset(start, 1, size); > return start; > } > > long access_file(const char *filename, long size, long rounds) > { > int fd, i; > volatile char *start1, *end1, *start2; > const int page_size = getpagesize(); > long sum = 0; > > fd = open(filename, O_RDONLY); > if (fd == -1) { > perror("open"); > exit(1); > } > > /* > * Some applications, e.g. chrome, use a lot of executable file > * pages, map some of the pages with PROT_EXEC flag to simulate > * the behavior. > */ > start1 = mmap(NULL, size / 2, PROT_READ | PROT_EXEC, MAP_SHARED, > fd, 0); > if (start1 == MAP_FAILED) { > perror("mmap"); > exit(1); > } > end1 = start1 + size / 2; > > start2 = mmap(NULL, size / 2, PROT_READ, MAP_SHARED, fd, size / 2); > if (start2 == MAP_FAILED) { > perror("mmap"); > exit(1); > } > > for (i = 0; i < rounds; ++i) { > struct timeval before, after; > volatile char *ptr1 = start1, *ptr2 = start2; > gettimeofday(&before, NULL); > for (; ptr1 < end1; ptr1 += page_size, ptr2 += page_size) > sum += *ptr1 + *ptr2; > gettimeofday(&after, NULL); > printf("File access time, round %d: %f (sec)\n", i, > (after.tv_sec - before.tv_sec) + > (after.tv_usec - before.tv_usec) / 1000000.0); > } > return sum; > } > > int main(int argc, char *argv[]) > { > const long MB = 1024 * 1024; > long anon_mb, file_mb, file_rounds; > const char filename[] = "large"; > long *ret1; > long ret2; > > if (argc != 4) { > printf("usage: thrash ANON_MB FILE_MB FILE_ROUNDS\n"); > exit(0); > } > anon_mb = atoi(argv[1]); > file_mb = atoi(argv[2]); > file_rounds = atoi(argv[3]); > > fallocate_file(filename, file_mb * MB); > printf("Allocate %ld MB anonymous pages\n", anon_mb); > ret1 = alloc_anon(anon_mb * MB); > printf("Access %ld MB file pages\n", file_mb); > ret2 = access_file(filename, file_mb * MB, file_rounds); > printf("Print result to prevent optimization: %ld\n", > *ret1 + ret2); > return 0; > } > ---8<--- > > Running the test program on 2GB RAM VM with kernel 5.2.0-rc5, the > program fills ram with 2048 MB memory, access a 200 MB file for 10 > times. Without this patch, the file cache is dropped aggresively and > every access to the file is from disk. > > $ ./thrash 2048 200 10 > Allocate 2048 MB anonymous pages > Access 200 MB file pages > File access time, round 0: 2.489316 (sec) > File access time, round 1: 2.581277 (sec) > File access time, round 2: 2.487624 (sec) > File access time, round 3: 2.449100 (sec) > File access time, round 4: 2.420423 (sec) > File access time, round 5: 2.343411 (sec) > File access time, round 6: 2.454833 (sec) > File access time, round 7: 2.483398 (sec) > File access time, round 8: 2.572701 (sec) > File access time, round 9: 2.493014 (sec) > > With this patch, these file pages can be cached. > > $ ./thrash 2048 200 10 > Allocate 2048 MB anonymous pages > Access 200 MB file pages > File access time, round 0: 2.475189 (sec) > File access time, round 1: 2.440777 (sec) > File access time, round 2: 2.411671 (sec) > File access time, round 3: 1.955267 (sec) > File access time, round 4: 0.029924 (sec) > File access time, round 5: 0.000808 (sec) > File access time, round 6: 0.000771 (sec) > File access time, round 7: 0.000746 (sec) > File access time, round 8: 0.000738 (sec) > File access time, round 9: 0.000747 (sec) How does the reclaim behave with workloads with file backed data set not fitting into the memory? Aren't we going to to swap a lot - something that the heuristic is protecting from? > Fixes: e9868505987a ("mm,vmscan: only evict file pages when we have plenty") > Fixes: 7c5bd705d8f9 ("mm: memcg: only evict file pages when we have plenty") > Signed-off-by: Kuo-Hsin Yang > Acked-by: Johannes Weiner > Cc: # 4.12+ -- Michal Hocko SUSE Labs