Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp230925ybb; Tue, 14 Apr 2020 23:48:51 -0700 (PDT) X-Google-Smtp-Source: APiQypK9YdLTyLiszAe4ngHrWIaYoh3e57JSWR8k9JYUA8eMkf/HkhZDWwb1YA+n81naFMuMIrSY X-Received: by 2002:a17:906:8549:: with SMTP id h9mr3479235ejy.145.1586933331622; Tue, 14 Apr 2020 23:48:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586933331; cv=none; d=google.com; s=arc-20160816; b=HiPkkmSoE3PFAvzdrYbuXVFlP00LrfQqgN6zug8aAAssNCFSIXo/SBttr3pFob1gj9 EcsNm3AbN1b3K+7lGR4BH3Y4uLU7M7zIRnEcaelXGv+H/wSTbsTrowBRLXoeK5kbS1wt oJxCqBMHeWK17bx6pzE+4IYr6atop8JPScnOLcETrhWpp/qkeYX845KwR5JWTJVGMPKv u/0EgtlTx7uw4YCS7a8h8z8cwozajBN8wvNu5XWDzBg1rykYfxo3X8vxTYoX6BUYvNIv hZYhLT03YFYGEv2W0VCGfTO30hyxMsi8mcmnQ7klSKNPdYgbsojApBzvO+p+B7U2+GBD RH+w== 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=mKfl+AewevjW1Y7NnaQMkTO4U5AB+ar98eQs8ax5HQ4=; b=hT6AkouaK47VbX6hy+i1X80VDulpOe+nVryF6UF2VGRy5MN5sEEIAKxLTh4PiPDDtK nCWaAVBO5nsQyrCkgK1hz1JiOfMvzU6emvlurlaFH3jDNNEa11or+SV38Ybp1MPNpEbZ hwwb/2+8gt7adumySf+aIIB7TdvfEaV3XdtkYn15lomqpU3L8McM6Fwq8T03zIaZujSe Jc/9QluUBAOOijxdDI6clnLC+lrKyVJ2kob6wbdM5wcwLN6JZdRpgQzrPinAbzLtDU1E JiRIupF43GdSXinJdfYEk9835tTHImO8VwCzFALBCebYRDGVllS8aAqSoQtgMcmGZS8G BOxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for 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 z6si10625614edp.440.2020.04.14.23.48.27; Tue, 14 Apr 2020 23:48:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for 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: best guess record for 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 S2403791AbgDNBb3 (ORCPT + 99 others); Mon, 13 Apr 2020 21:31:29 -0400 Received: from mga12.intel.com ([192.55.52.136]:46087 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727867AbgDNBb2 (ORCPT ); Mon, 13 Apr 2020 21:31:28 -0400 IronPort-SDR: p98+ZZ6QYuqxpLTalD8H3Sd3s5rg1eqNDc6Jwm5Ls09fONbKbejrc9DVcrizFSt/RF6XksEwim RhRT5QIvqy9Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2020 18:31:26 -0700 IronPort-SDR: kOzw4nBLI2e7kjIdZeS0pezxBLzcZ/XvN8vKLi1t0VHDBzG0XjIK7125/jN/gUjRz6L0zxodKh TcJmLRoO8icA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,381,1580803200"; d="scan'208";a="253051814" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.23]) by orsmga003.jf.intel.com with ESMTP; 13 Apr 2020 18:31:24 -0700 From: "Huang\, Ying" To: Andrea Righi Cc: Andrew Morton , Minchan Kim , Anchal Agarwal , , Subject: Re: [PATCH v2] mm: swap: use fixed-size readahead during swapoff References: <20200413111810.GA801367@xps-13> <87a73f7d71.fsf@yhuang-dev.intel.com> <20200413133150.GA810380@xps-13> Date: Tue, 14 Apr 2020 09:31:24 +0800 In-Reply-To: <20200413133150.GA810380@xps-13> (Andrea Righi's message of "Mon, 13 Apr 2020 15:31:50 +0200") Message-ID: <87wo6i6efn.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: > On Mon, Apr 13, 2020 at 09:00:34PM +0800, Huang, Ying wrote: >> Andrea Righi writes: >> >> [snip] >> >> > diff --git a/mm/swap_state.c b/mm/swap_state.c >> > index ebed37bbf7a3..c71abc8df304 100644 >> > --- a/mm/swap_state.c >> > +++ b/mm/swap_state.c >> > @@ -20,6 +20,7 @@ >> > #include >> > #include >> > #include >> > +#include >> > #include >> > >> > #include >> > @@ -507,6 +508,14 @@ static unsigned long swapin_nr_pages(unsigned long offset) >> > max_pages = 1 << READ_ONCE(page_cluster); >> > if (max_pages <= 1) >> > return 1; >> > + /* >> > + * If current task is using too much memory or swapoff is running >> > + * simply use the max readahead size. Since we likely want to load a >> > + * lot of pages back into memory, using a fixed-size max readhaead can >> > + * give better performance in this case. >> > + */ >> > + if (oom_task_origin(current)) >> > + return max_pages; >> > >> > hits = atomic_xchg(&swapin_readahead_hits, 0); >> > pages = __swapin_nr_pages(prev_offset, offset, hits, max_pages, >> >> Thinks this again. If my understanding were correct, the accessing >> pattern during swapoff is sequential, why swap readahead doesn't work? >> If so, can you root cause that firstly? > > Theoretically if the pattern is sequential the current heuristic should > already select a big readahead size, but apparently it's not doing that. > > I'll repeat my tests tracing the readahead size during swapoff to see > exactly what's going on here. I haven't verify it. It may be helpful to call lookup_swap_cache() before swapin_readahead() in unuse_pte_range(). The theory behind it is to update the swap readahead statistics via lookup_swap_cache(). Best Regards, Huang, Ying