From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A516C433DF for ; Tue, 9 Jun 2020 06:19:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE4D0207F9 for ; Tue, 9 Jun 2020 06:19:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE4D0207F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 60C056B0027; Tue, 9 Jun 2020 02:19:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE316B0028; Tue, 9 Jun 2020 02:19:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D1E46B0029; Tue, 9 Jun 2020 02:19:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 36DC46B0027 for ; Tue, 9 Jun 2020 02:19:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E9E08801CFBB for ; Tue, 9 Jun 2020 06:19:36 +0000 (UTC) X-FDA: 76908671952.25.tray97_421125726dc0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id BC4CC1803A12A for ; Tue, 9 Jun 2020 06:19:36 +0000 (UTC) X-HE-Tag: tray97_421125726dc0 X-Filterd-Recvd-Size: 5225 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Tue, 9 Jun 2020 06:19:36 +0000 (UTC) Received: from mail-wr1-f72.google.com ([209.85.221.72]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jiXbi-0008Bl-NQ for linux-mm@kvack.org; Tue, 09 Jun 2020 06:19:34 +0000 Received: by mail-wr1-f72.google.com with SMTP id l18so8217167wrm.0 for ; Mon, 08 Jun 2020 23:19: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:references :mime-version:content-disposition:in-reply-to; bh=qjb8qEBmbuxNu1rg1xJE74o0cBFJkDEp4RqvXUvcj7g=; b=QdvrU5r0d3ONsyD7O7fbkMIIFhjn+cj6Op5xJPyUqAZDANPo1Ii72SSX0CPpROe9p7 iEjZCQVvFa7YZ66GdVHpI5q8U30WZiQ6VOc0BWVXODRt8yAV5m5cUehmmg05Ok8NOAJ+ YuiNidyM/L5VqZzTeCQ5fTv4NZE5cF0ORMWGb2C40UFYOo/LNrj8/wd72FPEzvJhmYjE VPAmpd4m91Q0U3D5gId+w6N+Phvt9wVGzPgxwCpHwwGhGQWunSUHzUyreCfN7sa9hK4Q ipNhHPT0MHjU3Eq+/YodbcTJ0B9pNQoW7UT/nXqyfUGK26509sHxlQkb/CH+qp8PpDPX mXmA== X-Gm-Message-State: AOAM531PtNE20jdOXBICBVdTljsVvdlUite2t3K56XOd81tYQX/Zexvh wPLr6lCOHncUWLLcpscPEqIojzn+iQBz5Y7xSC3w0xoHGG3+VpgvahainyDYAJ8R7Gyn4Y8Zf1n uRN/M2XyAOp5NWOoxHlZ6t3JEGXar X-Received: by 2002:adf:f611:: with SMTP id t17mr2488209wrp.69.1591683574300; Mon, 08 Jun 2020 23:19:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHarr5VZT6oF9G6VEGI1D72bnLATgetDEJahbmVGkSpxTPq0pDEZ9cDRwC9XjCiXG/RArUkw== X-Received: by 2002:adf:f611:: with SMTP id t17mr2488180wrp.69.1591683573984; Mon, 08 Jun 2020 23:19:33 -0700 (PDT) Received: from localhost (host-79-43-135-105.retail.telecomitalia.it. [79.43.135.105]) by smtp.gmail.com with ESMTPSA id s7sm2062721wrr.60.2020.06.08.23.19.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 23:19:33 -0700 (PDT) Date: Tue, 9 Jun 2020 08:19:31 +0200 From: Andrea Righi To: Luigi Semenzato Cc: Pavel Machek , linux-kernel , Linux Memory Management List , Linux PM , Andrew Morton , Len Brown , "Rafael J . Wysocki" Subject: Re: [RFC PATCH 2/2] PM: hibernate: introduce opportunistic memory reclaim Message-ID: <20200609061931.GH8413@xps-13> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: BC4CC1803A12A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 08, 2020 at 03:23:22PM -0700, Luigi Semenzato wrote: > Hi Andrea, > > 1. This mechanism is quite general. It is possible that, although > hibernation may be an important use, there will be other uses for it. > I suggest leaving the hibernation example and performance analysis, > but not mentioning PM or hibernation in the patch subject. I was actually thinking to make this feature even more generic, since there might be other potential users of this forced "memory reclaim" feature outside hibernation. So, instead of adding the new sysfs files under /sys/power/mm_reclaim/, maybe move them to /sys/kernel/mm/ (since it's more like a mm feature, rather than a PM/hibernation feature). > > 2. It may be useful to have run_show() return the number of pages > reclaimed in the last attempt. (I had suggested something similar in > https://lore.kernel.org/linux-mm/CAA25o9SxajRaa+ZyhvTYdaKdXokcrNYXgEUimax4sUJGCmRYLA@mail.gmail.com/). I like this idea, I'll add that in the next version. > > 3. It is not clear how much mm_reclaim/release is going to help. If > the preloading of the swapped-out pages uses some kind of LIFO order, > and can batch multiple pages, then it might help. Otherwise demand > paging is likely to be more effective. If the preloading does indeed > help, it may be useful to explain why in the commit message. Swap readahead helps a lot in terms of performance if we preload all at once. But I agree that for the majority of cases on-demand paging just works fine. My specific use-case for mm_reclaim/release is to make sure a VM that is just resumed is immediately "fast" by preloading the swapped-out pages back to memory all at once. Without mm_reclaim/release I've been using the trick of running swapoff followed by a swapon to force all the pages back to memory, but it's kinda ugly and I was looking for a better way to do this. I've been trying also the ptrace() + reading all the VMAs via /proc/pid/mem, it works, but it's not as fast as swapoff+swapon or mm_reclaim/release. I'll report performance numbers of mm_reclaim/release vs ptrace() + /proc/pid/mem in the next version of this patch. > > Thanks! Thanks for your review! -Andrea