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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9570DC43468 for ; Mon, 21 Sep 2020 15:36:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 181ED20888 for ; Mon, 21 Sep 2020 15:36:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 181ED20888 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F247900089; Mon, 21 Sep 2020 11:36:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A1E0900083; Mon, 21 Sep 2020 11:36:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48F37900089; Mon, 21 Sep 2020 11:36:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id 2FA50900083 for ; Mon, 21 Sep 2020 11:36:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4C91F3631 for ; Mon, 21 Sep 2020 15:36:43 +0000 (UTC) X-FDA: 77287471086.28.bait54_310bf2527146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 25ED86C04 for ; Mon, 21 Sep 2020 15:36:43 +0000 (UTC) X-HE-Tag: bait54_310bf2527146 X-Filterd-Recvd-Size: 5203 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 15:36:42 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id 26so9052726ois.5 for ; Mon, 21 Sep 2020 08:36:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YP2Z3oRhK3eHSoO4BzbyEvH/PYDM17b6EUAJ8a+UJbY=; b=QsJ3zuaQN3GAp+kv6DEBGE4rXoxYo97IA7ZlH/jxW2FYiuEXhhzmtvjquATYzcglpC dyjuacIl3c8+vC8NCnFmixgy2je3Br5KSW9Ih0d5rnsLlj0pfZM/UaCRJXPNnSIoVfx0 0cUVKUDKzzJGeJ4ESql8/lqWIguPfCJtRBIjpqSOi4yvVBBpCM8JyZpUVcTCDtQdZT3P g4S7j6P7YUKE6wi47lYTCwLs2vpkBg8z+pbSI0RHlhjWsSUiiEqAXIV8sbNaPwr12hiV Th6ZvGYMMId1SVMHlV4gBCne87B1VxC1mD5fpKTndsXO5PbyMrnvuFR3qXjtRri+fjhY V7cA== X-Gm-Message-State: AOAM53155ef6Oswh3MXEwUnDg6DTZkTvrRgcJAnFkoO/zM80sxyFafcn GP5rVkF1CK+yDdG03P47IMDVjc+Nn6kGgWWAv5U= X-Google-Smtp-Source: ABdhPJww9oxNxeRQH2N770Y4aJZAy5wWFPihKynYSdxaeVByKSUNpuumDTSh7xvGVB++b11h6B4FGSMBlhz9smJmGBo= X-Received: by 2002:aca:df84:: with SMTP id w126mr63347oig.103.1600702601836; Mon, 21 Sep 2020 08:36:41 -0700 (PDT) MIME-Version: 1.0 References: <20200609061931.GH8413@xps-13> In-Reply-To: <20200609061931.GH8413@xps-13> From: "Rafael J. Wysocki" Date: Mon, 21 Sep 2020 17:36:30 +0200 Message-ID: Subject: Re: [RFC PATCH 2/2] PM: hibernate: introduce opportunistic memory reclaim To: Andrea Righi Cc: Luigi Semenzato , Pavel Machek , linux-kernel , Linux Memory Management List , Linux PM , Andrew Morton , Len Brown , "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" 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: Hi Andrea, On Tue, Jun 9, 2020 at 8:19 AM Andrea Righi wrote: > > 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. Sorry for the huge delay. I'm wondering what your vision regarding the use of this mechanism in practice is? In the "Testing" part of the changelog you say that "in the 5.7-mm_reclaim case a user-space daemon detects when the system is idle and triggers the opportunistic memory reclaim via /sys/power/mm_reclaim/run", but this may not be entirely practical, because hibernation is not triggered every time the system is idle. In particular, how much time is required for the opportunistic reclaim to run before hibernation so as to make a significant difference? Thanks!