Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp126347ybg; Tue, 22 Oct 2019 17:20:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4gNKjQUpR4YVo/+Dv0PV+49rAtVxZnLZd2lyIu5aJKkHeDWvo2ZwazO/y5us/trwWS+SP X-Received: by 2002:a50:ab01:: with SMTP id s1mr11055872edc.192.1571790052841; Tue, 22 Oct 2019 17:20:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571790052; cv=none; d=google.com; s=arc-20160816; b=J5vD2oVqjOPaFBa10u4oZX8Zid3may6Bi5qc6umcnrU9Ec77GvRxdA6fVYXM+g5VBa NNrdaKf/aVMV6hl5+M+8LhXSs7VP52f970WChTPYiTSpfMFn+FbpDOk1KRi6myxWkklI bnFSCoFwdQq40jsGnh4o7CmCiTHMiyf0E7OSaviOb2LD7CC6sNEpan1/geAS5XoZtFOn GvvwUaeInKS1K4dalTYRiTnZpN0vd8V/PppX3fK+jLaYqeyc3QyAdH2by4o1IxW5XHsy WLmUjdkIngsycZW8B2EM7PWUFw7fRoZE6f6Na5F0a+ADS9LSHhxl5tYE1n3Dtm3Qu1fq nLQA== 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:dkim-signature; bh=WIdjvj3kcTlPGjglhXDelm+EyQ4AXkSZ1XXSBXmy05M=; b=VnOrgXTeN6+S6TUzStqAHHWro24KYmnrs4i227rMCEQ4RGoPstLeTJiKoNDyv/2hA8 2YLeCoby6waaDog28FK61AMZAkmVyMTRqWj9f7LCDeGhddTZHlZt8z4Gc57QRGobCMI/ mawqfthqI/jAFrUN6rKIYrCdvXE+K0kurb8z+oRdk9BSTNY2b2lp/RTEfyQ+eAMeqwEI S7sY8pF5VKfvKanQ33DlvErW7U/oL8wDjG2AoYqRVyTVNEs/6sBUR2a03xifEdKX+S+0 fSGU0WgsFx6vL/Ddf7GpTuIcAsf39QXW/zc7AxRQEEyYqmQFoYy7FMdETvBhIoPMvvzV AWfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YzL3h8hg; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w1si12671422edt.288.2019.10.22.17.20.28; Tue, 22 Oct 2019 17:20:52 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=YzL3h8hg; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389664AbfJVXZ4 (ORCPT + 99 others); Tue, 22 Oct 2019 19:25:56 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:53361 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727403AbfJVXZz (ORCPT ); Tue, 22 Oct 2019 19:25:55 -0400 Received: by mail-wm1-f68.google.com with SMTP id i13so3844117wmd.3 for ; Tue, 22 Oct 2019 16:25:53 -0700 (PDT) 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=WIdjvj3kcTlPGjglhXDelm+EyQ4AXkSZ1XXSBXmy05M=; b=YzL3h8hgvCV4nviJ4p9KC3zaLwubCJcDm3zcroeVzc+KXKo8KJtm9sCz+kMJfcleHe 3WdLR48GXsxIkjFl67gQxkAeiMer/wBUQTmup2/9k5Hqb9z+4anezjLWJBPrnrxLQcsN q2lgGmEKQTMUOu5AHutq/xNE8K0f8X82cDl9DB9rhBp2YcpKmN5RQynQJiT1NrUjiEzG y3NBw2iL12HXr/myUYYCEDKqUX2389LSKscBsgvg5q1zpmAOxtkQo+AilaIk/RQF178k bQkoqxA3ti9eFA1nI6QgoL9EgnpS8wewMWVPrMiqP0tQRiiaixVFyqMA/L1+WAWfz7OQ BK2g== 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=WIdjvj3kcTlPGjglhXDelm+EyQ4AXkSZ1XXSBXmy05M=; b=R1tElACf/zQNyVK3o6o/1h/EiNyL35LDa2Pr9PE0FuiFVhl5F7b/cOX1a+sPTPl34m f5UKP+S5aH1RZ2LkJmLsNQsGWUFMDtPUrGCuFYZWtpkcuol1INBbhAiYFBS0/5ISLcTN +2cu7XpSGkcb4D4Fqu8SFD73mAfBVvxy0WG618tJR9Wttf6lWa9G8Z07NQlsxxA6jUhP ixPyY0QyOLIopO9y3MhK+Op7nDk6pyNHvKjowwIA+ZPRHC22/3mdLN1pcoHmwZftit0u /5ZFeSznGbkeazM8lqm0SQsIP4T41/JRt1UnZ9oC+HZBPiwi7DsyIJJNsw9Vwll/pwjD 0hEA== X-Gm-Message-State: APjAAAWzpFqQYMGaT/Ei0WFFt6vtIapc5Ygdw0HWYHyapy7H6soLvC2V zxETBRWMI1FGQA4nKeVcxMP5CtGlGTeo7CmhAF4MeQ== X-Received: by 2002:a1c:2986:: with SMTP id p128mr3248874wmp.173.1571786752358; Tue, 22 Oct 2019 16:25:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luigi Semenzato Date: Tue, 22 Oct 2019 16:25:40 -0700 Message-ID: Subject: Re: is hibernation usable? To: "Rafael J. Wysocki" Cc: linux-kernel , Linux PM , Andrew Morton , Geoff Pike , Bas Nowaira , 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 4:16 PM Rafael J. Wysocki wrote: > > On Wed, Oct 23, 2019 at 12:53 AM Luigi Semenzato wrote: > > > > On Tue, Oct 22, 2019 at 3:14 PM Rafael J. Wysocki wrote: > > > > > > On Tue, Oct 22, 2019 at 11:26 PM Luigi Semenzato wrote: > > > > > > > > Thank you for the quick reply! > > > > > > > > On Tue, Oct 22, 2019 at 1:57 PM Rafael J. Wysocki wrote: > > > > > > > > > > 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. > > > > > > > > Sorry, I don't understand this. Are you saying that, for instance, > > > > you can resume a 30 GB image on a 32 GB device, but that image could > > > > only have been created on a 64 GB device? > > > > > > Had it been possible to create images larger than 50% of memory during > > > hibernation, it would have been possible to load them during resume as > > > well. > > > > > > The resume code doesn't have a 50% of RAM limitation, the image > > > creation code does. > > > > Thanks a lot for the clarifications. > > > > It is possible that you and I have different definitions of "working > > in general". My main issue ia that I would like image creation (i.e. > > entering hibernation) to work with >50% of RAM in use, and I am > > extrapolating that other people would like that too. I can see that > > there are many uses where this is not needed though, especially if you > > mostly care about resume. > > Also note that you need to be precise about what ">50% of RAM in use" > means. For example, AFAICS hibernation works just fine for many cases > in which MemFree is way below 50% of MemTotal. Yes, I agree, that's tricky to explain. Of course here I mean the number of "saveable" pages, as defined in hibernate.c, and clearly anon pages are always saveable. > > > > > > > > > 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. > > > > > > > > Again, I don't understand. Why did you make that suggestion then? > > > > > > > > > hibernate_preallocate_memory() manages to free a sufficient amount of > > > > > memory on my system every time. > > > > > > > > Unfortunately this doesn't work for me. I may have described a simple > > > > experiment: on a 4GB device, create two large processes like this: > > > > > > > > dd if=/dev/zero bs=1100M count=1 | sleep infinity & > > > > dd if=/dev/zero bs=1100M count=1 | sleep infinity & > > > > > > > > so that more than 50% of TotalMem is used for anonymous pages. Then > > > > echo disk > /sys/power/state fails with ENOMEM. > > > > > > I guess hibernate_preallocate_memory() is not able to free enough > > > memory for itself in that case. > > > > > > > Is this supposed to work? > > > > > > Yes, it is, in general. > > > > > > > Maybe I am doing something wrong? > > > > Hibernation works before I create the dd processes. After I force > > > > some of those pages to a separate swap device, hibernation works too, > > > > so those pages aren't mlocked or anything. > > > > > > It looks like you are doing something that is not covered by > > > hibernate_preallocate_memory(). > > > > > > > > > 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. > > > > > > > > I apologize if I am doing something stupid and I should know better > > > > before I waste other people's time. I have been trying to explain > > > > these issues as best as I can. I have a reproducible failure. I'll > > > > be happy to provide any additional detail. > > > > > > Simply put, hibernation, as implemented today, needs to allocate over > > > 50% of RAM (or at least as much as to be able to copy all of the > > > non-free pages) for image creation. If it cannot do that, it will > > > fail and you know how to prevent it from allocating enough memory in a > > > reproducible way. AFAICS that's a situation in which every attempt to > > > allocate 50% of memory for any other purpose will fail as well. > > > > > > Frankly, you are first to report this problem, so it arguably is not > > > common. It looks like hibernate_preallocate_memory() may be improved > > > to cover that case, but then the question is how much more complicated > > > it will have to become for this purpose and whether or not that's > > > worth pursuing. > > > > Right. I was hoping to discuss that. Is it easier to do in the > > kernel what I am trying to do at user level, i.e. force swap of excess > > pages (possibly to a separate device or partition) so that enough > > pages are freed up to make hibernate_preallocate_memory always > > succeed? > > It should at least be possible to do that, but it's been a while since > I last looked at hibernate_preallocate_memory() etc. > > > I started reading the swap code, but it is entangled with > > page reclaim and I haven't seen a simple solution, neither do I know > > if there is one and how long it would take to find it, or code around > > it. (However I haven't looked yet at how it works when memcgroup > > limits are lowered---that may give me good ideas).