Message ID | 20221208180209.50845-6-ryncsn@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp345150wrr; Thu, 8 Dec 2022 10:09:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Hfw1/zutJ5BzwsNn2Zv7eG9evES3BuU6VgPZp/UYjQurxfLS8fml/Ee6KtbcDk8bPTuZ8 X-Received: by 2002:a17:902:da82:b0:189:adf8:54f8 with SMTP id j2-20020a170902da8200b00189adf854f8mr37000735plx.81.1670522945430; Thu, 08 Dec 2022 10:09:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670522945; cv=none; d=google.com; s=arc-20160816; b=fzbFGP2mLsynBAL2sVgD5IsG7MkhYBmd2vGMYE2s9bBfSeUaIOQRp+aRMQ5N+CyEYS RcxJ6BwA4vYySJQxRihzQRA1VF4bU48+venxJaHXXqvPy2EZMu3kHws1TT8qyuDD3Q6w DfZCopo2v2rgKxGeZDIuzEDHxq02SJfNXIzdWBmEupuI/422BPbSkhSd/vk7VD4qky+q bC5W0y2LkyFBWbkvZuoY9a+VuoRI3jcRQmZ5CRYsuCsRhej6iTizHW0hz+/8F1+w+1kJ nylr3Jifr3W6trcSX02Bo5MGqwrFzZ9jVGfgf360bHHQFIwuI/vRrBcHmfFKFZGmT+fH jkiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version:reply-to :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ltPbBrCKZDS7mJn+bR+RqAKCWGPP/Hc1SQkH2hWVmXg=; b=hrYkPDqiBw05WW2ZrSPwE3UrXz3+filTM6o8BrjWt1pOj0IdPEpzT7cj8KObN1fHWM KW46ZFr2Pao8luhk6OFjI5w6Pg3+i8I5jnI6pUe5vEaAyLj9ABlkrzKEPFRFPvJSGbSo oMPCN0ps+DDVecrgiCVCV5q/rn1XDhcCyU634tyAFY4UilJnBhtlbYiX/frLUA7C/CP/ 3kr/UEDKPqcLvAMHHxblJPhU0rbLF/cNWbHW+PdQKGX8PXjGPorQquTsTaaeMOwlcuML eZD5PXnb+66y3LXAkxBAZV0X7bOSbD8gJ9T1VkHgJJGhIGxTFvpSRePzT2xj/8vlZ6Mj eS/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hRgCXWOP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q33-20020a631f61000000b00476ef0d44f6si24086591pgm.672.2022.12.08.10.08.52; Thu, 08 Dec 2022 10:09:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hRgCXWOP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230019AbiLHSEC (ORCPT <rfc822;foxyelen666@gmail.com> + 99 others); Thu, 8 Dec 2022 13:04:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230007AbiLHSDq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 8 Dec 2022 13:03:46 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38676AE4F4 for <linux-kernel@vger.kernel.org>; Thu, 8 Dec 2022 10:03:38 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so5464233pjs.4 for <linux-kernel@vger.kernel.org>; Thu, 08 Dec 2022 10:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=ltPbBrCKZDS7mJn+bR+RqAKCWGPP/Hc1SQkH2hWVmXg=; b=hRgCXWOPDDo7RlbXFKoM69xuCbwt8WjzTaUsg01akGxMhNwABD12DyylexVFkD/7Mu M+qrq5HV/MDlhFQ2jxpJkr9HNBE7YMfEZaXVGRTNrwlZFE00eokpEecQWj3j6JrbPCbA 1zHxzkaBVjYkjr1s2oWBVUR/5nbzmiSc+/4+6qJl50hF8eFgPh9NnQuk0lo+FhfUqNe6 F3QleTfoMD2zNv1+SBcEq0q4ftrAofnh81ysKVSlErGBas3RbClmzj9QYTQztCMaIqID gUiM72cYqHlrpjl8RiTv3askqJOawjDqYKnOo2KlhUkvFGpDTtXyhTuqVoXIozJUmNZa Jslw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ltPbBrCKZDS7mJn+bR+RqAKCWGPP/Hc1SQkH2hWVmXg=; b=S8GbmdEaaJ15ZfSu89GZnVlKJeE2tH/TE8XGzvRWNebysPFY7GUehDE84EXQCGVG0b xMTrBfJk1IVFdCYcz3hQJ1iNm/sqWerwxAIe7qr/Vui2ojXOX4JSfhEtSc9kTCeVcjfX MhDFvswpvCwi2DDSL7tekgo8hFF6Nq6RssRyabUHXKTZ1pM/k0G91jumERUvN6wCMWP3 rWznlWXlrfpl3DLU2DGtvFv4JW81F6nidahWbkln8/E4nx2zxFRK7us/Uo8AQPsy/bQp aSGrN6xI2iV7RoLL25JZ+mVNhmYuKN3CZEe7oavR9X7hQVl4wCaQZAIeqow+cOkR2zMz n3AQ== X-Gm-Message-State: ANoB5ply8ySWdXqsekZBmbo+21OrIE+1FfirJGQla69sU6ee9CF80pVJ VPNgRtyG6VGWik56JRWplvc= X-Received: by 2002:a17:90a:7606:b0:219:823e:6726 with SMTP id s6-20020a17090a760600b00219823e6726mr2920444pjk.19.1670522617801; Thu, 08 Dec 2022 10:03:37 -0800 (PST) Received: from localhost.localdomain ([198.13.51.166]) by smtp.gmail.com with ESMTPSA id x23-20020a63db57000000b004785e505bcdsm13377909pgi.51.2022.12.08.10.03.32 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 08 Dec 2022 10:03:37 -0800 (PST) From: Kairui Song <ryncsn@gmail.com> To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, Miaohe Lin <linmiaohe@huawei.com>, David Hildenbrand <david@redhat.com>, "Huang, Ying" <ying.huang@intel.com>, Hugh Dickins <hughd@google.com>, Kairui Song <kasong@tencent.com> Subject: [PATCH 5/5] swap: avoid ra statistic lost when swapin races Date: Fri, 9 Dec 2022 02:02:09 +0800 Message-Id: <20221208180209.50845-6-ryncsn@gmail.com> X-Mailer: git-send-email 2.35.2 In-Reply-To: <20221208180209.50845-1-ryncsn@gmail.com> References: <20221208180209.50845-1-ryncsn@gmail.com> Reply-To: Kairui Song <kasong@tencent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751670268023179798?= X-GMAIL-MSGID: =?utf-8?q?1751670268023179798?= |
Series |
Clean up and fixes for swap
|
|
Commit Message
Kairui Song
Dec. 8, 2022, 6:02 p.m. UTC
From: Kairui Song <kasong@tencent.com> __read_swap_cache_async should just call swap_cache_get_folio for trying to look up the swap cache. Because swap_cache_get_folio handles the readahead statistic, and clears the RA flag, looking up the cache directly will skip these parts. And the comment no longer applies after commit 442701e7058b ("mm/swap: remove swap_cache_info statistics"), just remove them. Fixes: 442701e7058b ("mm/swap: remove swap_cache_info statistics") Signed-off-by: Kairui Song <kasong@tencent.com> --- mm/swap_state.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
Comments
On Fri, Dec 09, 2022 at 02:02:09AM +0800, Kairui Song wrote: > From: Kairui Song <kasong@tencent.com> > > __read_swap_cache_async should just call swap_cache_get_folio for trying > to look up the swap cache. Because swap_cache_get_folio handles the > readahead statistic, and clears the RA flag, looking up the cache > directly will skip these parts. > > And the comment no longer applies after commit 442701e7058b > ("mm/swap: remove swap_cache_info statistics"), just remove them. But what about the readahead stats? > Fixes: 442701e7058b ("mm/swap: remove swap_cache_info statistics") > Signed-off-by: Kairui Song <kasong@tencent.com> > --- > mm/swap_state.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/mm/swap_state.c b/mm/swap_state.c > index eba388f67741..f39cfb62551d 100644 > --- a/mm/swap_state.c > +++ b/mm/swap_state.c > @@ -418,15 +418,12 @@ struct page *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, > for (;;) { > int err; > /* > - * First check the swap cache. Since this is normally > - * called after swap_cache_get_folio() failed, re-calling > - * that would confuse statistics. > + * First check the swap cache in case of race. > */ > si = get_swap_device(entry); > if (!si) > return NULL; > - folio = filemap_get_folio(swap_address_space(entry), > - swp_offset(entry)); > + folio = swap_cache_get_folio(entry, vma, addr); > put_swap_device(si); > if (folio) > return folio_file_page(folio, swp_offset(entry)); > -- > 2.35.2 > >
Matthew Wilcox <willy@infradead.org> 于2022年12月9日周五 03:14写道: > Hi, thanks for the review. > On Fri, Dec 09, 2022 at 02:02:09AM +0800, Kairui Song wrote: > > From: Kairui Song <kasong@tencent.com> > > > > __read_swap_cache_async should just call swap_cache_get_folio for trying > > to look up the swap cache. Because swap_cache_get_folio handles the > > readahead statistic, and clears the RA flag, looking up the cache > > directly will skip these parts. > > > > And the comment no longer applies after commit 442701e7058b > > ("mm/swap: remove swap_cache_info statistics"), just remove them. > > But what about the readahead stats? > Shouldn't readahead stats be accounted here? __read_swap_cache_async is called by swap read in path, if it hits the swap cache, and the page have readahead page flag set, then accounting that readahead should be just the right thing todo. And the readahead flag is checked with folio_test_clear_readahead, so there should be no issue about repeated accounting. Only the addr info of the swap_readahead_info could be updated for multiple times by racing readers, but I think that seems fine, since we don't know which swap read comes later in case of race, just let the last reader that hits the swap cache update the address info of readahead makes sense to me. Or do you mean I should update the comment about the readahead stat instead of just drop the commnet?
Kairui Song <ryncsn@gmail.com> writes: > Matthew Wilcox <willy@infradead.org> 于2022年12月9日周五 03:14写道: >> > > Hi, thanks for the review. > >> On Fri, Dec 09, 2022 at 02:02:09AM +0800, Kairui Song wrote: >> > From: Kairui Song <kasong@tencent.com> >> > >> > __read_swap_cache_async should just call swap_cache_get_folio for trying >> > to look up the swap cache. Because swap_cache_get_folio handles the >> > readahead statistic, and clears the RA flag, looking up the cache >> > directly will skip these parts. >> > >> > And the comment no longer applies after commit 442701e7058b >> > ("mm/swap: remove swap_cache_info statistics"), just remove them. >> >> But what about the readahead stats? >> > > Shouldn't readahead stats be accounted here? __read_swap_cache_async > is called by swap read in path, if it hits the swap cache, and the > page have readahead page flag set, then accounting that readahead > should be just the right thing todo. And the readahead flag is checked > with folio_test_clear_readahead, so there should be no issue about > repeated accounting. > > Only the addr info of the swap_readahead_info could be updated for > multiple times by racing readers, but I think that seems fine, since > we don't know which swap read comes later in case of race, just let > the last reader that hits the swap cache update the address info of > readahead makes sense to me. > > Or do you mean I should update the comment about the readahead stat > instead of just drop the commnet? __read_swap_cache_async() is called by readahead too (swap_vma_readahead/__read_swap_cache_async). I don't think that it's a good idea to do swap readahead operation in this function. Best Regards, Huang, Ying
Huang, Ying <ying.huang@intel.com> 于2022年12月11日周日 20:03写道: > > Kairui Song <ryncsn@gmail.com> writes: > > > Matthew Wilcox <willy@infradead.org> 于2022年12月9日周五 03:14写道: > >> > > > > Hi, thanks for the review. > > > >> On Fri, Dec 09, 2022 at 02:02:09AM +0800, Kairui Song wrote: > >> > From: Kairui Song <kasong@tencent.com> > >> > > >> > __read_swap_cache_async should just call swap_cache_get_folio for trying > >> > to look up the swap cache. Because swap_cache_get_folio handles the > >> > readahead statistic, and clears the RA flag, looking up the cache > >> > directly will skip these parts. > >> > > >> > And the comment no longer applies after commit 442701e7058b > >> > ("mm/swap: remove swap_cache_info statistics"), just remove them. > >> > >> But what about the readahead stats? > >> > > > > Shouldn't readahead stats be accounted here? __read_swap_cache_async > > is called by swap read in path, if it hits the swap cache, and the > > page have readahead page flag set, then accounting that readahead > > should be just the right thing todo. And the readahead flag is checked > > with folio_test_clear_readahead, so there should be no issue about > > repeated accounting. > > > > Only the addr info of the swap_readahead_info could be updated for > > multiple times by racing readers, but I think that seems fine, since > > we don't know which swap read comes later in case of race, just let > > the last reader that hits the swap cache update the address info of > > readahead makes sense to me. > > > > Or do you mean I should update the comment about the readahead stat > > instead of just drop the commnet? > > __read_swap_cache_async() is called by readahead too > (swap_vma_readahead/__read_swap_cache_async). I don't think that it's a > good idea to do swap readahead operation in this function. Ah, I got it. Thanks for pointing out the issue, I'll drop this patch. > > Best Regards, > Huang, Ying
diff --git a/mm/swap_state.c b/mm/swap_state.c index eba388f67741..f39cfb62551d 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -418,15 +418,12 @@ struct page *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, for (;;) { int err; /* - * First check the swap cache. Since this is normally - * called after swap_cache_get_folio() failed, re-calling - * that would confuse statistics. + * First check the swap cache in case of race. */ si = get_swap_device(entry); if (!si) return NULL; - folio = filemap_get_folio(swap_address_space(entry), - swp_offset(entry)); + folio = swap_cache_get_folio(entry, vma, addr); put_swap_device(si); if (folio) return folio_file_page(folio, swp_offset(entry));