Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp89223ybz; Thu, 16 Apr 2020 20:06:12 -0700 (PDT) X-Google-Smtp-Source: APiQypIMInmBtrKWf9c1qFzwAMuSiV95dSR8oQwCvntLxFH4m4pmowjm5RhhcWNEAxPor4aJGSr5 X-Received: by 2002:a50:e8cb:: with SMTP id l11mr1180274edn.174.1587092771922; Thu, 16 Apr 2020 20:06:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587092771; cv=none; d=google.com; s=arc-20160816; b=cnLTbt91plNJ8YKOUi+3C/kJE2oQX2iTK1hHJsppTcbZhTn+w/j0SulQ32nnn5UVy9 p1K5PQeCXmCMKgI9vf2eh/3P/en0PMozVZUib0jpWv07iuG+rcxfv0Qhi2pInqKbnj9U az86qevmMHxhfppZQfi6Yg78Xtrf9vnW9ZRj7k+1P3cQgfCu7Uln1ACxPMWfVkgscF9Q mQsIhKLwEDP4XLAO0WLWh0F6rpn/YzIe72tSIdIIc9vUo2ltHbb3F6U6KsXzU2Iz4Rx6 nxIGSKN1n1TK3KbTmrZSpbfwPrko1c+B9ipNTGyV9kjHntme6fMLh+1JY7bXi44g2sUQ XJHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:ironport-sdr :ironport-sdr; bh=d3sEGMxjqU3aJxAZoW+1P16c1pT2RiMBZBVpMk2f7ZE=; b=kgmqq26c55OPBqHFx5XzGIAMxx+ehvCVqjg53BxDiaY1MnNh1vz/exgV+Z0xzSvEzK kRyAV6daakYIVynlHUaRKa39/0vyDeGz9FZ3rKmqxrceOUYZQXO0mXVzwrjK6X7SwLq7 Ch9xCjeRYMFUNcQmUVLjI8zN12vJ4qZsIRxzh1aRZmLM3/uSnfurNi3BtRAV2bUnX33r mscJRXBJ/DCPSnua2rKJGXsvlriXjX9vCqXDFF3b0Qa7TbP1TyvEfUm8btfxhXw9oZu1 Qz2VfImNAzdaP33nGjCsRZhHpZvQdK9Ij4MDCyYBlsHJnYgEM9XqBL2iTEMdFSIEqH1d uDcA== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a3si13214222eje.187.2020.04.16.20.05.22; Thu, 16 Apr 2020 20:06:11 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729447AbgDQDBZ (ORCPT + 99 others); Thu, 16 Apr 2020 23:01:25 -0400 Received: from mga04.intel.com ([192.55.52.120]:21668 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbgDQDBZ (ORCPT ); Thu, 16 Apr 2020 23:01:25 -0400 IronPort-SDR: M5EIEsAo9IUlYXQ9fj8IK7R9TAjjf751f6Mab25GQ/A/4W07lmjbtoxhxfgtnSt5EcKjzCgtOi Z+Ygmz8ATj4g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2020 20:01:25 -0700 IronPort-SDR: 4xXBe1wnECRz/UV85LMKUwzgWH5fHFhfCBvqCT4xRlF3F0nTHNQLb9gHFmsHaGegX0rnJCKXYe +nq561+7bwVg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,393,1580803200"; d="scan'208";a="254072337" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.23]) by orsmga003.jf.intel.com with ESMTP; 16 Apr 2020 20:01:23 -0700 From: "Huang\, Ying" To: Andrea Righi Cc: Andrew Morton , Minchan Kim , Anchal Agarwal , , Subject: Re: [PATCH v3] mm: swap: properly update readahead statistics in unuse_pte_range() References: <20200416180132.GB3352@xps-13> Date: Fri, 17 Apr 2020 11:01:22 +0800 In-Reply-To: <20200416180132.GB3352@xps-13> (Andrea Righi's message of "Thu, 16 Apr 2020 20:01:32 +0200") Message-ID: <871romvmrh.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrea Righi writes: > 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. It's more important to describe why we need this patch in the patch description. So, please add some information about your use case. And please focus on the technical part instead of the business part. > 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" Thanks! But you don't need to do this. You can add my Reviewed-by after we have finished the work on patch description. Best Regards, Huang, Ying