Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp231245ybb; Tue, 14 Apr 2020 23:49:25 -0700 (PDT) X-Google-Smtp-Source: APiQypIprtBdJGLFJGOhX0HijtfPig30WTl1lsJLqGDdVtcfKjpsVErL7NY1iO2AGBiT2ufabYTA X-Received: by 2002:a17:906:27d1:: with SMTP id k17mr3563040ejc.134.1586933365533; Tue, 14 Apr 2020 23:49:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586933365; cv=none; d=google.com; s=arc-20160816; b=sT9rVu5qvUleT9fgJLWm1IcSNl03s7gaabB4UWFWVRYK7KQoUIVx36RHE2r8cc8eaJ T+u6m1fD52pzfshvk4UkfC2PTebdspS+1gQq+oIXD6F0rvaL3KjuF2VZe1WHtAxWrKVN UeAd0EFTaQRd6pzUDQhYjVx3rcaJ3JBwufg6SXlniJgnpR2cV4Cert9qJCuRXgmS8A/I lyEHDZBWvw6LasNGAp1JHe5fl63ehgipzBfYGFApGBb1LGWATpKxwbql9nzLX1YFBgDG FjGMnBlmkz5LIEPypIrxt02y117DRNGUEPykl+0SCkrTTrUc/kU9LcLTR4s1Q+vEpBir LyVQ== 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=Fajy3CIPfVKp08/75B+BjTc7/D9Yo4xFDyqF/PDDQTM=; b=Ly14OMzdlbWcd7RSMUq8nDj9Ohic/pbmQqzA7dcPcY5igMicxCS6rgl2u0mMNdFMPW Bwclb1PafU742Q5EPGo5i5KJE6FWGxD6zJJyGC+lPK6soMa8l8PeY9OKBFpNY1V8J28M Xwr6YnwB56FEaERNT2xXAw6Q+/wkSJLcjqOhjEkA/++u8kGVXfkHiAqjiEpjnI6J+rQv VPwElXRcd1LtpaEZZ40ezIT2M0wlAKZfoYQF1WarrEUnNADf91rP0QwEKJOdc5rGmXkv HwLN3Xiof5tVfaorNPBRDYAgH8OaBVv4qI/kp8cRg1YlHz2QY0hhSJxNXmTpLXy+A46E Ickw== 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 gq24si9510606ejb.222.2020.04.14.23.49.02; Tue, 14 Apr 2020 23:49:25 -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 S2403842AbgDNBpo (ORCPT + 99 others); Mon, 13 Apr 2020 21:45:44 -0400 Received: from mga05.intel.com ([192.55.52.43]:1314 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728252AbgDNBpn (ORCPT ); Mon, 13 Apr 2020 21:45:43 -0400 IronPort-SDR: peIj0ED6tBRRwL2Hkjr8iGVJTt0N4TVvH1cazX0JiPGsYnRxnTDxz3wbiTiBNezpq1zC+OiKmP +NqSHqs2iTng== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2020 18:45:42 -0700 IronPort-SDR: UexRrFsjgpHMwK9A/oshz470Jyjmt45pDLe5ZgnWgwlNmXbLHxziiQ0KeEPirtr6TXqNxuNBWf KflPfxfdcp7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,381,1580803200"; d="scan'208";a="256353181" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.23]) by orsmga006.jf.intel.com with ESMTP; 13 Apr 2020 18:45:40 -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> <875ze37cle.fsf@yhuang-dev.intel.com> <20200413132658.GB801367@xps-13> Date: Tue, 14 Apr 2020 09:45:39 +0800 In-Reply-To: <20200413132658.GB801367@xps-13> (Andrea Righi's message of "Mon, 13 Apr 2020 15:26:58 +0200") Message-ID: <87sgh66drw.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:13:33PM +0800, Huang, Ying wrote: >> Andrea Righi writes: >> >> > The global swap-in readahead policy takes in account the previous access >> > patterns, using a scaling heuristic to determine the optimal readahead >> > chunk dynamically. >> > >> > This works pretty well in most cases, but like any heuristic there are >> > specific cases when this approach is not ideal, for example the swapoff >> > scenario. >> > >> > During swapoff we just want to load back into memory all the swapped-out >> > pages and for this specific use case a fixed-size readahead is more >> > efficient. >> > >> > The specific use case this patch is addressing is to improve swapoff >> > performance when a VM has been hibernated, resumed and all memory needs >> > to be forced back to RAM by disabling swap (see the test case below). >> >> Why do you need to swapoff after resuming? The swap device isn't used >> except hibernation? I guess the process is, >> >> 1) add swap device to VM >> 2) hibernate >> 3) resume >> 4) swapoff > > Correct, the swap device is used only for hibernation, when the system > is resumed the swap is disabled (swapoff). > >> >> Some pages are swapped out in step 2? If os, can we just set >> /proc/sys/vm/swappiness to 0 to avoid swapping in step 2? > > Sorry, can you elaborate more on this? All anonymous pages are swapped > out during step 2, it doesn't matter if we set swappiness to 0, they are > swapped out anyway, because we need save them somewhere in order to > hibernate, shutting down the system. All pages will be written to the swap device in step 2. But the normal swapout path isn't used. So these pages will be restored in step 3 instead of step 4. But at the beginning of step 2, system may try to reclaim some pages, the reclaimed anonymous pages will be restored in step 4. This may be avoided via setting /proc/sys/vm/swappiness to 0 before step 2. Best Regards, Huang, Ying > Thanks, > -Andrea