Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp102153ybg; Tue, 22 Oct 2019 16:56:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUWXhvBM3Myb1ogoEW1Qs6ueaVAxZCDiCvxLPN8m0gyT7VFJnyGBXu019NcRvW7Xns9K4D X-Received: by 2002:a17:906:c739:: with SMTP id fj25mr18451248ejb.164.1571788563060; Tue, 22 Oct 2019 16:56:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571788563; cv=none; d=google.com; s=arc-20160816; b=cmWtHOdHaB0k/3QyVwcY/pXzjj2SJRRsXjbMd5Y8iNEa946zBa826lqkSegXFBbNxc bZDDrGZGWAxEpk3S0TT/k6gSsyQK+ZEnWsyCGWW0vSD0VnDMkYyesWM3/xTo4utwpZXa AEZ0FSQ0XyJ8lgeOP463hJd/nj0gXFxHQ/DuVnmIngRbHGuE6syJKCZtTOqGTlO7MNlb 63emEijzTqQeOarRkWzDD3dLG4tP0fNfVW7+mJ+TwXYOoPOKfMt8wdriBgIoDileBPwJ EWKoa7QcwHaZNy60F511pKdL6XhmvgBeIi7zf/ciT9jjHdDG6jVsZnoOoXoke7DM41W+ Cq3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=GptL/7TorSVDMwb9IC9D0CwrTWrvmemL9jOU1eTDxRw=; b=tcYJQrGSps38AvSD8NxCvEa3nuBlvRX5hCuwWkLAcdsuSpGqpsizIzrxRFsZCPego/ wPnVud4x9cEY5BSApQ0oyHcgnVdLNCdGiH1bIxlJWyvO5CQAg2r373ZJp+fMPbLrWX8H z/SUaK/5vKxvGJ7TTaFDOdiFmN3w06beKMPc4xPyO5tSfJApb77CD3X4ZCMD0ye4UGzu OFNX0uvaWdIfUn3+EWGDg/cMTJrPSTpkS1ijucW7ygLJHU9sHGEmNfM4Q/6rOqA3qU68 udmk/fO+T5q/Puw/MY8P6A5Z9RaXHtWVLu74tnOWxA6YNWGJPMHtdDm5x+44oXSgTVTE j1mQ== 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 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r12si830916edi.272.2019.10.22.16.55.39; Tue, 22 Oct 2019 16:56:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731059AbfJVU5e (ORCPT + 99 others); Tue, 22 Oct 2019 16:57:34 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:42050 "EHLO mail-oi1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725874AbfJVU5d (ORCPT ); Tue, 22 Oct 2019 16:57:33 -0400 Received: by mail-oi1-f178.google.com with SMTP id i185so15427374oif.9; Tue, 22 Oct 2019 13:57:33 -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=GptL/7TorSVDMwb9IC9D0CwrTWrvmemL9jOU1eTDxRw=; b=TMmwQrogi0BSNwcV728fP3AUXRLbPOzcZnNesImOvgrdKQr2OmZoUksW6B5CWBJler E53YRSajr5xyoAh5asmDCyQuhFn15nG+aGx6Arlx2sh+nuLBPVXgKJ7zuQmhUdiHloC5 H3mNYZlwplIbGAJ6p5lMLu5O2hcmi7lS/YPWKOW5HVaFN4h6XwqIr3o2mq0tdzAg5huB b1ZdRgM6bXUH75wIgHUl8x909+phRrsKnntNOCGwynV9dcdv6R5THUN1y+2Tcd4NggIc ZST26Kcbly1DA/C0OGpSLwHIYXfrRf/Lpese6Wp1ItElEwnkRWeOFy4/mGBBTwdDwP2y Whhw== X-Gm-Message-State: APjAAAXKXcsnwCRpDWX5MNn4Fp63UOZJLM7d9H4D9zyqN4XxKSn5YyHU NaWxfKUz/plmZyJ+fIJkoxdiIYqztskXQK58A9A= X-Received: by 2002:aca:5885:: with SMTP id m127mr4777280oib.110.1571777852342; Tue, 22 Oct 2019 13:57:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 22 Oct 2019 22:57:20 +0200 Message-ID: Subject: Re: is hibernation usable? To: Luigi Semenzato Cc: linux-kernel , Linux PM , Andrew Morton , Geoff Pike , Bas Nowaira , "Rafael J. Wysocki" , Sonny Rao , Brian Geffon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 22, 2019 at 10:09 PM Luigi Semenzato wrote: > > Following a thread in linux-pm > (https://marc.info/?l=linux-mm&m=157012300901871) I have some issues > that may be of general interest. > > 1. To the best of my knowledge, Linux hibernation is guaranteed to > fail if more than 1/2 of total RAM is in use (for instance, by > anonymous pages). My knowledge is based on evidence, experiments, > code inspection, the thread above, and a comment in > Documentation/swsusp.txt, copied here: So I use it on a regular basis (i.e. every day) on a system that often has over 50% or RAM in use and it all works. I also know about other people using it on a regular basis. For all of these users, it is usable. > "Instead, we load the image into unused memory and then atomically > copy it back to it original location. This implies, of course, a > maximum image size of half the amount of memory." That isn't right any more. An image that is loaded during resume can, in fact, be larger than 50% of RAM. An image that is created during hibernation, however, cannot. > 2. There's no simple/general workaround. Rafael suggested on the > thread "Whatever doesn't fit into 50% of RAM needs to be swapped out > before hibernation". This is a good suggestion: I am actually close > to achieving this using memcgroups, but it's a fair amount of work, > and a fairly special case. Not everybody uses memcgroups, and I don't > know of other reliable ways of forcing swap from user level. I don't need to do anything like that. hibernate_preallocate_memory() manages to free a sufficient amount of memory on my system every time. > 3. A feature that works only when 1/2 of total RAM can be allocated > is, in my opinion, not usable, except possibly under special > circumstances, such as mine. Most of the available articles and > documentation do not mention this important fact (but for the excerpt > I mentioned, which is not in a prominent position). It can be used with over 1/2 of RAM allocated and that is quite easy to demonstrate. Honestly, I'm not sure what your problem is really. > Two questions then: > > A. Should the documentation be changed to reflect this fact more > clearly? I feel that the current situation is a disservice to the > user community. Propose changes. > B. Would it be worthwhile to improve the hibernation code to remove > this limitation? Is this of interest to anybody (other than me)? Again, propose specific changes.