Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1689697ybz; Thu, 16 Apr 2020 13:45:29 -0700 (PDT) X-Google-Smtp-Source: APiQypKspvIk0HMc3PDnTgQs2YUtb+SmvvBhRYDJXDh74RJYMS6FziCWNhYxzMU62sEgvet7/v1+ X-Received: by 2002:a50:85c4:: with SMTP id q4mr42363edh.147.1587069929635; Thu, 16 Apr 2020 13:45:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587069929; cv=none; d=google.com; s=arc-20160816; b=vZZkkqcQkffgzkUA9lsn2pgU0ceabFnsh4tgMNyRQd1mmwmxHSBx4tAN79xWvDX16s 6fr9t4Qo+HMuAthoKqC/qk4Gn3nZUUG60KWCCLVfSoGO6rS+AAPsgcpU/DNjNx+fqZXa YbqYSgU7yimfD+NtgKzyeGEL7R2348lEOX204WqE0wVF9lCXc/vsS3ZrHJ+cURBrTSTI nJxC7SXTO//Sevx/QnU4TtNQUF68lcIk87vCeX+twgQwdZve+fZjoHfWsnCMVCD2IlFz L9rFnY+j3JJVI/zPPz/zWyaQ7YoSPDS+O4fB9d0Ra5DxTdkfab3GU3oFQwtfNM4LY5lj baSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:mime-version :message-id:subject:cc:to:from:date; bh=lqszIaXl46cTzGLGeC0g1ccnl6uoouKrI1pXyrzOud8=; b=B1cCJREDVsXLrj8AqnZhtutRFdrYPYQlk+7WFJeiIQKdzc0+t9a4SBeS4PL/FrlT6Z pQxB4xjtgRh3F5ERbH/nBQA2QKyTVgYkaamucLCXhRHfDMOdWruSP4meVQl3c5y+s6hq Fj2Ep+FeB9fKiBuAM5KxvtQjlDGpCeLQ7yJ6KjLoL4SBnDwwuoIjmrcQ9o/vfJcPL7DG WjvHo6zrwQHQ4smIMcmbvVHL/OxGL9dUq3AipPeAI8EHdzrcQgfZoXKtyfW7LrYeNDTS l6Rpcq2e+lchxaDm7YMCO7nhi1pamrC//NF+cEZkPBynUwbegfxulpF6+kpT/njk89vB svHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 5si13247995ejx.392.2020.04.16.13.45.07; Thu, 16 Apr 2020 13:45:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437145AbgDPSBi (ORCPT + 99 others); Thu, 16 Apr 2020 14:01:38 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:32859 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727794AbgDPSBh (ORCPT ); Thu, 16 Apr 2020 14:01:37 -0400 Received: from mail-wr1-f69.google.com ([209.85.221.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jP8pS-0005Jy-SL for linux-kernel@vger.kernel.org; Thu, 16 Apr 2020 18:01:34 +0000 Received: by mail-wr1-f69.google.com with SMTP id m15so2164184wrb.0 for ; Thu, 16 Apr 2020 11:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=lqszIaXl46cTzGLGeC0g1ccnl6uoouKrI1pXyrzOud8=; b=CmfAxzL+2JYbDSLgaBz7vGNwL0jvP7bzVPdm0RSsP0RgkjE9zUoYzddkEmlyb1l5ep 7ExV+jbrbFa1O5QIKf8RBxLCvQFHJlvdICHguXiq95hCby7QqdzMG66+GSFTmaZCjMz4 e0p3FL0tyiGkX52qixYS0/kOrvOEaiG9nXIVsTqTdEjGYMnQsRXN+44v822xZ22xGJb4 9IdwVxuvTK1BdfSBFiwKHUEyke0hVDw93F8kDWJwiyNU5wv4XCHywTpiiJcqu9WeRqSZ EocuwIEaiax9zSxHiuTlprAuGqqNaJrrRaSCWdMFdjwsByDN8azQqotmR4krz7Ytiuyk a5sQ== X-Gm-Message-State: AGi0PuYHZWyLgWh4S75+Hg7tboAoeW4Kz1ggJEnP9ANJ7IJkQnOAT9lV voCi3rqs0rrsOhtWoT/z1s/C/Yighd4zKCHSR91vHw4FKT6lbm0aXZsvwFv0KQTUrJ2Rjc1kWIK hAW8zqTxX1hNlE8J6JOvbsWTkfrJm/V0b3fw1pKXu0w== X-Received: by 2002:adf:e791:: with SMTP id n17mr28844565wrm.217.1587060094536; Thu, 16 Apr 2020 11:01:34 -0700 (PDT) X-Received: by 2002:adf:e791:: with SMTP id n17mr28844526wrm.217.1587060094178; Thu, 16 Apr 2020 11:01:34 -0700 (PDT) Received: from localhost (host123-127-dynamic.36-79-r.retail.telecomitalia.it. [79.36.127.123]) by smtp.gmail.com with ESMTPSA id n6sm4400810wmc.28.2020.04.16.11.01.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 11:01:33 -0700 (PDT) Date: Thu, 16 Apr 2020 20:01:32 +0200 From: Andrea Righi To: Andrew Morton Cc: Huang Ying , Minchan Kim , Anchal Agarwal , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v3] mm: swap: properly update readahead statistics in unuse_pte_range() Message-ID: <20200416180132.GB3352@xps-13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In unuse_pte_range() we blindly swap-in pages without checking if the swap entry is already present in the swap cache. By doing this, the hit/miss ratio used by the swap readahead heuristic is not properly updated and this leads to non-optimal performance during swapoff. Tracing the distribution of the readahead size returned by the swap readahead heuristic during swapoff shows that a small readahead size is used most of the time as if we had only misses (this happens both with cluster and vma readahead), for example: r::swapin_nr_pages(unsigned long offset):unsigned long:$retval COUNT EVENT 36948 $retval = 8 44151 $retval = 4 49290 $retval = 1 527771 $retval = 2 Checking if the swap entry is present in the swap cache, instead, allows to properly update the readahead statistics and the heuristic behaves in a better way during swapoff, selecting a bigger readahead size: r::swapin_nr_pages(unsigned long offset):unsigned long:$retval COUNT EVENT 1618 $retval = 1 4960 $retval = 2 41315 $retval = 4 103521 $retval = 8 In terms of swapoff performance the result is the following: Testing environment =================== - Host: CPU: 1.8GHz Intel Core i7-8565U (quad-core, 8MB cache) HDD: PC401 NVMe SK hynix 512GB MEM: 16GB - Guest (kvm): 8GB of RAM virtio block driver 16GB swap file on ext4 (/swapfile) Test case ========= - allocate 85% of memory - `systemctl hibernate` to force all the pages to be swapped-out to the swap file - resume the system - measure the time that swapoff takes to complete: # /usr/bin/time swapoff /swapfile Result (swapoff time) ====== 5.6 vanilla 5.6 w/ this patch ----------- ----------------- cluster-readahead 22.09s 12.19s vma-readahead 18.20s 15.33s Signed-off-by: "Huang, Ying" Signed-off-by: Andrea Righi --- Changes in v3: - properly update swap readahead statistics instead of forcing a fixed-size readahead mm/swapfile.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 5871a2aa86a5..f8bf926c9c8f 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1937,10 +1937,14 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd, pte_unmap(pte); swap_map = &si->swap_map[offset]; - vmf.vma = vma; - vmf.address = addr; - vmf.pmd = pmd; - page = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE, &vmf); + page = lookup_swap_cache(entry, vma, addr); + if (!page) { + vmf.vma = vma; + vmf.address = addr; + vmf.pmd = pmd; + page = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE, + &vmf); + } if (!page) { if (*swap_map == 0 || *swap_map == SWAP_MAP_BAD) goto try_next; -- 2.25.1