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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 99A17C11D10 for ; Thu, 20 Feb 2020 17:16:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D51F24672 for ; Thu, 20 Feb 2020 17:16:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="o6KBQw3t" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728679AbgBTRQ3 (ORCPT ); Thu, 20 Feb 2020 12:16:29 -0500 Received: from mail-il1-f194.google.com ([209.85.166.194]:37354 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728173AbgBTRQ2 (ORCPT ); Thu, 20 Feb 2020 12:16:28 -0500 Received: by mail-il1-f194.google.com with SMTP id v13so24328154iln.4 for ; Thu, 20 Feb 2020 09:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xGI4ZH0DU8aHO9nNniE5WRLgtSUtlx4p2LoUqqkDqAw=; b=o6KBQw3tzkTc6yXRtzpHDxT0cumt02XwKR5Vd6072iHdJXK1ZDzJOol/gBCNv2dexK LbHWWGTw/cPo8gHZu9QuP04rQ+TlluDuVN+AFr+vubid7A/+zZvo1yiciSBDjoQIYxV1 H59P3JVSF4BYYXZANZzZvs/u4pHrhmdvf9HBQmXdgPwk3PuTwITNYV2a7vLn1NAwLfkQ PAQVp+pQuAAZ0BUhApNKsCnoWUZg6km0pk3BrhR6eYbQdT0AfiyMEsMsmPNFQzk5pGfC imbMIGTMrWpFJdsj89UE6feyHUrA0rbL1cpowr7JVgFkyIBG9MpI1L4dUkxw9amdpCHE kgrQ== 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=xGI4ZH0DU8aHO9nNniE5WRLgtSUtlx4p2LoUqqkDqAw=; b=hM0sJ/B3Tzt50NxZN2inYa7i5Tslsu5JenCRqpi+snh/UrGqn8TmTEtdcTAF8i600r iA7DIPwluBEPUO5xk5cbiB/WmaGvTvlaeTzzOQ0OD49KwYImW/9CPRdbv6uqkf/evpJ0 fVYT6BOXWyVhcx628Y+E6D/3xjgM4gSfUlen1kvMpSX6A0h5EtZL1B7sfZ+4mhzZdUVJ CHjE6i6HHxKLI5g6hO0yMycKnlNsJXxYvADmFe0E72Z2s5c/K1qQzyulrN8oJtsoEq8D rnYtMF6D9GbIEJdzjJrwILxpvyCaeV15lKwFVP7OeJSjAZ7FimyJRV2PMV588qg6jbyN IW3g== X-Gm-Message-State: APjAAAXwXgIAnMMaFUSfm7KBZsNEmalh63o/4JDIKgHHc5P4l6zpmIga M73PSY9aCcA+r1Ircj5CUplBEKjPEHreGwekni6pnw== X-Google-Smtp-Source: APXvYqxHadhtfe835KKRHQxq80OQhhIBJ6ibIuxbD9uZQd8Hfld9kR1QEQho6ZgOC1h9PYOqkiEgZ46Oq5sIIK8rgjc= X-Received: by 2002:a92:8dda:: with SMTP id w87mr30073572ill.55.1582218986252; Thu, 20 Feb 2020 09:16:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Luigi Semenzato Date: Thu, 20 Feb 2020 09:16:15 -0800 Message-ID: Subject: Re: is hibernation usable? To: Chris Murphy Cc: Linux Memory Management List , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org I think this is the right group for the memory issues. I suspect that the problem with failed allocations (ENOMEM) boils down to the unreliability of the page allocator. In my experience, under pressure (i.e. pages must be swapped out to be reclaimed) allocations can fail even when in theory they should succeed. (I wish I were wrong and that someone would convincingly correct me.) I have a workaround in which I use memcgroups to free pages before starting hibernation. The cgroup request "echo $limit > .../memory.limit_in_bytes" blocks until memory usage in the chosen cgroup is below $limit. However, I have seen this request fail even when there is extra available swap space. The callback for the operation is mem_cgroup_resize_limit() (BTW I am looking at kernel version 4.3.5) and that code has a loop where try_to_free_pages() is called up to retry_count, which is at least 5. Why 5? One suspects that the writer of that code must have also realized that the page freeing request is unreliable and it's worth trying multiple times. So you could try something similar. I don't know if there are interfaces to try_to_free_pages() other than those in cgroups. If not, and you aren't using cgroups, one way might be to start several memory-eating processes (such as "dd if=/dev/zero bs=1G count=1 | sleep infinity") and monitor allocation, then when they use more than 50% of RAM kill them and immediately hibernate before the freed pages are reused. If you can build your custom kernel, maybe it's worth adding a sysfs entry to invoke try_to_free_pages(). You could also change the hibernation code to do that, but having the user-level hook may be more flexible. On Wed, Feb 19, 2020 at 6:56 PM Chris Murphy wrote: > > Also, is this the correct list for hibernation/swap discussion? Or linux-pm@? > > Thanks, > > Chris Murphy