From patchwork Mon Sep 21 01:43:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11788183 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 95AAE59D for ; Mon, 21 Sep 2020 01:43:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D9E8207DE for ; Mon, 21 Sep 2020 01:43:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="g0gmirYa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D9E8207DE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 33579900012; Sun, 20 Sep 2020 21:43:30 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 2E50A900009; Sun, 20 Sep 2020 21:43:30 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 222D7900012; Sun, 20 Sep 2020 21:43:30 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 0A610900009 for ; Sun, 20 Sep 2020 21:43:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C29A61EE6 for ; Mon, 21 Sep 2020 01:43:29 +0000 (UTC) X-FDA: 77285371338.13.thumb73_300dbd527141 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 9F32C18140B67 for ; Mon, 21 Sep 2020 01:43:29 +0000 (UTC) X-Spam-Summary: 1,0,0,e533a44a7c603748,d41d8cd98f00b204,laoar.shao@gmail.com,,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1345:1437:1534:1541:1711:1730:1747:1777:1792:2194:2199:2393:2553:2559:2562:2918:3138:3139:3140:3141:3142:3352:3865:3866:3867:3868:3870:3871:3874:4250:4321:5007:6119:6261:6653:7514:7875:7903:8660:9413:10004:11026:11658:11914:12043:12048:12296:12297:12438:12517:12519:12555:12895:13069:13148:13161:13229:13230:13255:13311:13357:14096:14181:14384:14394:14687:14721:21080:21324:21444:21451:21627:21666:21740:21939:30034:30054:30090,0,RBL:209.85.210.68:@gmail.com:.lbl8.mailshell.net-66.100.201.100 62.50.0.100;04y8559qari319jwdb5a3c7b8fgo8ocssfy75mnigm3yu3cnny5hmbjmfrz8ifj.bciit45uwhjy79rohys7reswowmtsagsf67g5udsrj86hh1aqnxnq4m71cybstj.q-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: thumb73_300dbd527141 X-Filterd-Recvd-Size: 4448 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 01:43:29 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id h17so10972708otr.1 for ; Sun, 20 Sep 2020 18:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=V2dp5aUeS4VgS3eOPIk+Ug8ut1GYRI38Dmff9LEHCuI=; b=g0gmirYaQED5JcHctzk0bPOc7QVIlEomCBb44w71amORPvUbkDRGmL7pTuokb+xoPG 8kuRD2DmUhOuxtu27W+YYUd6z7jLIj21qAMiZENRRM5eM/B6owmCCPszXDgEedgwI9jk xMCdqhH6K5p+BRnstW4c0YDlCkCA15QUFkJ/84KrtafJS6bc+Lltjb4/e/brmt5TR1Hm WtXMjWvpTLXkDk7v9rPQL7MbKrxxaKTPu0/+6Xzxm3/HeMwQdxybqeicCxleGI19Xi0Q j/eXF1/rewaCTajPHoJRm/EfTiXanoeCnVV5IXp2N5ddX7DtGUeukR51ChEP1B6i08YX feXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=V2dp5aUeS4VgS3eOPIk+Ug8ut1GYRI38Dmff9LEHCuI=; b=hfDvBWDN0JqVYLrEemaVwZjzpz/Y2MFAWqX6CJ8ntMIgDeNKwJlSBfMo2l8dLkxmWa xlzX/iFWm4g3SXuCW8hMda3GB53i4ro/IqAf1zKwcu9GNJRd+oMEzLjoHltsi+KJiTSo UQsixShcMUDcfJYKRLztas8vhRfPIWLkxhHt0hcBJlJponf6NDy+BY2FULgGqtfiIttx HoBr92QW/jKpdCj4PlaKwHSsHI681eiaqeASotQSn/kz2/Nsb2D6QbtsTVC4S5TP4cXS BHjVKbLIeaL/mEuZa0lJNESBWC0mq2kkCjxTKkD3nlVjjq8f1B53bjdRWJdLikBPfzWD /igQ== X-Gm-Message-State: AOAM5332DHOkN43VdvcocaOarLaeWTxU32/rotlVZgxKxO3MdhgkKwS1 ciZcDaKwBQueoXBxNk3QGyI= X-Google-Smtp-Source: ABdhPJwko7SbYr1Dt7JCg1MER01dxbVffa9llX0FUFPQ1jHuloR/hRFo+44NVdGaPqff800KEfKG4Q== X-Received: by 2002:a9d:490a:: with SMTP id e10mr31295762otf.325.1600652608590; Sun, 20 Sep 2020 18:43:28 -0700 (PDT) Received: from localhost.localdomain ([50.236.19.102]) by smtp.gmail.com with ESMTPSA id y7sm6296463oih.51.2020.09.20.18.43.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2020 18:43:27 -0700 (PDT) From: Yafang Shao To: akpm@linux-foundation.org, mgorman@suse.de, hannes@cmpxchg.org, mhocko@kernel.org Cc: linux-mm@kvack.org, Yafang Shao Subject: [PATCH] mm, fadvise: improve the expensive remote LRU cache draining after FADV_DONTNEED Date: Mon, 21 Sep 2020 09:43:17 +0800 Message-Id: <20200921014317.73915-1-laoar.shao@gmail.com> X-Mailer: git-send-email 2.17.2 (Apple Git-113) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Our users reported that there're some random latency spikes when their RT process is running. Finally we found that latency spike is caused by FADV_DONTNEED. Which may call lru_add_drain_all() to drain LRU cache on remote CPUs, and then waits the per-cpu work to complete. The wait time is uncertain, which may be tens millisecond. That behavior is unreasonable, because this process is bound to a specific CPU and the file is only accessed by itself, IOW, there should be no pagecache pages on a per-cpu pagevec of a remote CPU. That unreasonable behavior is partially caused by the wrong comparation of the number of invalidated pages and the number of the target. For example, if (count < (end_index - start_index + 1)) The count above is how many pages were invalidated in the local CPU, and (end_index - start_index + 1) is how many pages should be invalidated. The usage of (end_index - start_index + 1) is incorrect, because they are virtual addresses, which may not mapped to pages. We'd better use inode->i_data.nrpages as the target. Signed-off-by: Yafang Shao Cc: Mel Gorman Cc: Johannes Weiner --- mm/fadvise.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/fadvise.c b/mm/fadvise.c index 0e66f2aaeea3..ec25c91194a3 100644 --- a/mm/fadvise.c +++ b/mm/fadvise.c @@ -163,7 +163,7 @@ int generic_fadvise(struct file *file, loff_t offset, loff_t len, int advice) * a per-cpu pagevec for a remote CPU. Drain all * pagevecs and try again. */ - if (count < (end_index - start_index + 1)) { + if (count < inode->i_data.nrpages) { lru_add_drain_all(); invalidate_mapping_pages(mapping, start_index, end_index);