From patchwork Wed Feb 12 22:16:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Minchan Kim X-Patchwork-Id: 11379239 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 A550E921 for ; Wed, 12 Feb 2020 22:16:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71C3E21569 for ; Wed, 12 Feb 2020 22:16:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="m6bE/7Rq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71C3E21569 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BCBB86B049B; Wed, 12 Feb 2020 17:16:25 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id B7C696B049C; Wed, 12 Feb 2020 17:16:25 -0500 (EST) 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 A1BFD6B049D; Wed, 12 Feb 2020 17:16:25 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8A2466B049B for ; Wed, 12 Feb 2020 17:16:25 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3FD062C0D for ; Wed, 12 Feb 2020 22:16:25 +0000 (UTC) X-FDA: 76482884730.04.glue56_722c96850d73b X-Spam-Summary: 2,0,0,b39c5d59ec0b6c02,d41d8cd98f00b204,minchan.kim@gmail.com,:akpm@linux-foundation.org::linux-kernel@vger.kernel.org:jack@suse.cz:willy@infradead.org:josef@toxicpanda.com:hannes@cmpxchg.org:minchan@kernel.org:snazy@gmx.de,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1311:1314:1345:1359:1437:1515:1535:1542:1711:1730:1747:1777:1792:2393:2553:2559:2562:2693:2898:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:4605:5007:6261:6653:7903:9121:10004:11026:11473:11658:11914:12043:12295:12296:12297:12438:12517:12519:12555:12895:13894:14096:14181:14394:14721:21080:21324:21444:21451:21627:21987:21990:30054:30070:30090,0,RBL:209.85.215.193:@gmail.com:.lbl8.mailshell.net-62.50.0.100 66.100.201.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:25,LUA_SUMMARY:none X-HE-Tag: glue56_722c96850d73b X-Filterd-Recvd-Size: 5318 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Feb 2020 22:16:24 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id z12so1944873pgl.4 for ; Wed, 12 Feb 2020 14:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=qaiwdcinbwslO7EdATKJ134QGtzda46/f8mdpO086dY=; b=m6bE/7RqwfLpD1mq61rTzvjRR2ys5Ij1JFM0A0GKtF9HVX0WWCVA77x9kY/KpJrTfU JJSLpjs4+AlmTmCyUIciT3fcM6GnLxXwmzhl7i5raq1xxhDq2f93RnnIqEalWPJlEdwh JIhk6W9WGGsPQrafEVVXH+BhMV99HudisqiAGi0cyG/JwY3bw2cLmzjOK1hH6XJkuSrE YcKEbSinpUKN1NKpgYVsCo3VYMH33kH78gCd/DXZk+cVBUTCGpE6cnYRYOEvElvjvWbo 1L9lzfXy4ziL6/Y5k5HXPBcOSqL9FUEBkqFcpzqevigihsGkJimKiYplosv8jbHFaR4e e0/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=qaiwdcinbwslO7EdATKJ134QGtzda46/f8mdpO086dY=; b=MIFuRUnX35yOfoQQzWb6qzLfknV6qEsn4eToGbX7V1pN8uGoZ8VoFs0BFgWyRLx7Fv EQokW67szM5T38WR/rgbNr4EgOLXIXBCYDE0pvqe0jemlqHK1ARgsnZTF2geqhVV5GpJ anF2varse0SaKH+JF5krIFVIZU59eUZ4b88B7KASWyNkLctme8bfFLFHqA9ng+wNGfHK ULHSqOSEBT2Cp+/9vI9h+9wVmmd78FyNT3d8z9hMAjOP91ajOgUlVn+avxygKSH09ID2 eYMyZ8smUomywuAH66ioXQYphdEuogDSopbNe7GrlOsCaRNy1yCtb5vo8WNN7BfNXWn5 nbDw== X-Gm-Message-State: APjAAAVsEUldT89hfWZjc0Xwh5cJZosv0tqwzDyZS7RvWEv0bIa8zzeK jf+DlAtQCmur67psCpzzUZc= X-Google-Smtp-Source: APXvYqxEdmfgRh8AIV8cmXo8MbUCE3MelnAT6e18QMejlP/S1J+YS648UCx0O+NpBLpkC87Z+qw4Wg== X-Received: by 2002:a63:c30e:: with SMTP id c14mr15447571pgd.168.1581545783496; Wed, 12 Feb 2020 14:16:23 -0800 (PST) Received: from bbox-1.mtv.corp.google.com ([2620:15c:211:1:3e01:2939:5992:52da]) by smtp.gmail.com with ESMTPSA id o10sm117683pgq.68.2020.02.12.14.16.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 14:16:22 -0800 (PST) From: Minchan Kim To: Andrew Morton Cc: linux-mm , LKML , Jan Kara , Matthew Wilcox , Josef Bacik , Johannes Weiner , Minchan Kim , Robert Stupp Subject: [PATCH 2/3] mm: fix long time stall from mm_populate Date: Wed, 12 Feb 2020 14:16:13 -0800 Message-Id: <20200212221614.215302-2-minchan@kernel.org> X-Mailer: git-send-email 2.25.0.225.g125e21ebc7-goog In-Reply-To: <20200212221614.215302-1-minchan@kernel.org> References: <20200212221614.215302-1-minchan@kernel.org> MIME-Version: 1.0 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: Basically, fault handler releases mmap_sem before requesting readahead and then it is supposed to retry lookup the page from page cache with FAULT_FLAG_TRIED so that it avoids the live lock of infinite retry. However, what happens if the fault handler find a page from page cache and the page has readahead marker but are waiting under writeback? Plus one more condition, it happens under mm_populate which repeats faulting unless it encounters error. So let's assemble conditions below. __mm_populate for (...) get_user_pages(faluty_address) handle_mm_fault filemap_fault find a page form page(PG_uptodate|PG_readahead|PG_writeback) it will return VM_FAULT_RETRY continue with faulty_address IOW, it will repeat fault retry logic until the page will be written back in the long run. It makes big spike latency of several seconds. This patch solves the issue by turning off fault retry logic in second trial. Reviewed-by: Jan Kara Signed-off-by: Minchan Kim --- mm/gup.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index 1b521e0ac1de..b3f825092abf 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1196,6 +1196,7 @@ int __mm_populate(unsigned long start, unsigned long len, int ignore_errors) struct vm_area_struct *vma = NULL; int locked = 0; long ret = 0; + bool tried = false; end = start + len; @@ -1226,14 +1227,18 @@ int __mm_populate(unsigned long start, unsigned long len, int ignore_errors) * double checks the vma flags, so that it won't mlock pages * if the vma was already munlocked. */ - ret = populate_vma_page_range(vma, nstart, nend, &locked); + ret = populate_vma_page_range(vma, nstart, nend, + tried ? NULL : &locked); if (ret < 0) { if (ignore_errors) { ret = 0; continue; /* continue at next VMA */ } break; - } + } else if (ret == 0) + tried = true; + else + tried = false; nend = nstart + ret * PAGE_SIZE; ret = 0; }