Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4298436ybb; Tue, 14 Apr 2020 04:38:50 -0700 (PDT) X-Google-Smtp-Source: APiQypKaDfjpGKDXUmd7GCbMrSCYsy/CNSfuHLfEporXiCBOVWbfW6T2HMy9yYy8+c5JJyWAT/pf X-Received: by 2002:a17:906:30c5:: with SMTP id b5mr20877807ejb.102.1586864330519; Tue, 14 Apr 2020 04:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586864330; cv=none; d=google.com; s=arc-20160816; b=tsVBQ9Re2CBsSAxdqFnwjiRQXgIlTWTZTE5lb9MS64AMYHFIDcbbjEbV8kYGNcKQqY I/8Y8c8a7msS/YdJdDG5AOKBjcOetKOxbw/N+0FGNaK4bvCyKexdHoYGzcDR7qTKoymF nLEsS/bbMTztS/SJ5JJqOBVq+46Um5LIDKaUEPko1GsyyNvL8pvu3tbb7AZhBW+M8chR aJ1XORYeaZJw7bPelq2Cgeovi5ZGg7NkQI22T5/j2bRzfhuzzdU6Bp1tTPbNdT19WFGr Ym28dT62XbaqkTL5Ycf1C66QSMAK605lKb5hRO7Mya7J+dLRanSHES5cBGRIKhY2gYJQ 4gLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=8+a15+2Tn0eUrhKMyhOqb9Aptpj40p6nDpz6wADNeys=; b=a1dDa+DR9ToEgBY9pNht3O8zPqUS9auyFNWecU/9wzwiyBN0a8JpUWAQSTv92kUKMU vgxPZp6Pyh13nSFNamlcHCDIEshai2iG8wfjLAd9cW8q8eGrQUPqmT8zZ00t9tkzukWL FB5zrq3sXQA71BzHx+A94k64a5hh8rqZlglKx45/LVdWogCy7T/GiLiVUb4q8VKzsuWP xiCSgPwpXHOHdIcKEGTWb2YQ5FnVIeiMtHI50Z/7ZuU1YnAS8sTGj0+Oi3cy1u7ThDUD u7glTMdhYPoG8OTUlwkiEN7HUkfNpLFURRhtlppgJGklY2SgXYfiDbEfLolcWW/do8uR jcPg== 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=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m1si8192730eja.214.2020.04.14.04.38.26; Tue, 14 Apr 2020 04:38:50 -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=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729841AbgDMN1D (ORCPT + 99 others); Mon, 13 Apr 2020 09:27:03 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:35810 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728649AbgDMN1D (ORCPT ); Mon, 13 Apr 2020 09:27:03 -0400 Received: from mail-wr1-f70.google.com ([209.85.221.70]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jNz76-0003Pg-VI for linux-kernel@vger.kernel.org; Mon, 13 Apr 2020 13:27:01 +0000 Received: by mail-wr1-f70.google.com with SMTP id h95so6665349wrh.11 for ; Mon, 13 Apr 2020 06:27:00 -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:references :mime-version:content-disposition:in-reply-to; bh=8+a15+2Tn0eUrhKMyhOqb9Aptpj40p6nDpz6wADNeys=; b=HLWpZ9SlKSqJZwj23adgjPQ8FYWugKuj8WmmSg2Gu2flAIzf0yfvV/bF+n1IEfZAxd j7Eq/nAnGqEI93AxWSDCozmZgdJlhsXT+/k8WL4Yw1Epw7NVVzw6Gy6WdpderdGoNxLd w+rfTFAD1dlGr5oHyzWHHx5PQHhLEaCy8DMCKydg5bEWAR8e/coHa3m0d5wzJUmnibdL 7J+G/rwQC1tbiX7QJIH6+G0cMBQlxye4tnRHUAc8uXsTSlWL5b74Hm9+e82qKLrwc4Ra eeXOJDLnVOQWqz3zMrus3mT4z2wj6FcZaJBG6ZHpBAhgOjwmWm7nHCqikI87wVLN9kB/ 8Lrw== X-Gm-Message-State: AGi0PuZgDomv1zm5QfFpwUJ16FmkSZiX+IJNMMmxww1BMCRstb+wVMnr cB/38BOH9fEtoYj9FwpOpr3/NddZq/YQlLBi4eB0CQ3+eT241AuJ88rjx8N7qC0J/dy0nfPHerP 5QT/xKYunEiS9zuhfhe5mJUcR2bum8spyPjQnzST2dA== X-Received: by 2002:a1c:ba82:: with SMTP id k124mr19595748wmf.66.1586784420587; Mon, 13 Apr 2020 06:27:00 -0700 (PDT) X-Received: by 2002:a1c:ba82:: with SMTP id k124mr19595727wmf.66.1586784420259; Mon, 13 Apr 2020 06:27:00 -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 w12sm201227wrk.56.2020.04.13.06.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2020 06:26:59 -0700 (PDT) Date: Mon, 13 Apr 2020 15:26:58 +0200 From: Andrea Righi To: "Huang, Ying" Cc: Andrew Morton , Minchan Kim , Anchal Agarwal , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: swap: use fixed-size readahead during swapoff Message-ID: <20200413132658.GB801367@xps-13> References: <20200413111810.GA801367@xps-13> <875ze37cle.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875ze37cle.fsf@yhuang-dev.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, -Andrea