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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 C83D3C433E6 for ; Mon, 8 Feb 2021 13:46:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9DC5564DF0 for ; Mon, 8 Feb 2021 13:46:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230352AbhBHNqK (ORCPT ); Mon, 8 Feb 2021 08:46:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:21139 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231281AbhBHNm1 (ORCPT ); Mon, 8 Feb 2021 08:42:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612791660; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nIUUbNNEsbNY0qQ2TGTcojBdZ5jjYwt4zGR/YnTj+ow=; b=KjIR+1bFrSfGCuc4MjpjrVFYPVg6asVqPBW7yGJKosn77Zf5F3MwQDAt3lkIyCl52MDEwr D1ZRt3+ftfMEaFrV/6Vc+/MSGvjcQZnyMyOM6cgoyDR6B+z4H/pvTodEOKeuQ9eG9LPJMX 83DfaqI0wJ8Ou94/Abc4knappknl6OM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-144-Ransb7rrNHyz0DdVU9VPKA-1; Mon, 08 Feb 2021 08:40:56 -0500 X-MC-Unique: Ransb7rrNHyz0DdVU9VPKA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EA297107ACC7; Mon, 8 Feb 2021 13:40:51 +0000 (UTC) Received: from [10.36.113.240] (ovpn-113-240.ams2.redhat.com [10.36.113.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id A34BC60C5B; Mon, 8 Feb 2021 13:40:43 +0000 (UTC) Subject: Re: [PATCH v17 08/10] PM: hibernate: disable when there are active secretmem users To: Michal Hocko Cc: Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-9-rppt@kernel.org> <38c0cad4-ac55-28e4-81c6-4e0414f0620a@redhat.com> <770690dc-634a-78dd-0772-3aba1a3beba8@redhat.com> <21f4e742-1aab-f8ba-f0e7-40faa6d6c0bb@redhat.com> <5db6ac46-d4e1-3c68-22a0-94f2ecde8801@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Mon, 8 Feb 2021 14:40:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08.02.21 13:17, Michal Hocko wrote: > On Mon 08-02-21 12:26:31, David Hildenbrand wrote: > [...] >> My F33 system happily hibernates to disk, even with an application that >> succeeded in din doing an mlockall(). >> >> And it somewhat makes sense. Even my freshly-booted, idle F33 has >> >> $ cat /proc/meminfo | grep lock >> Mlocked: 4860 kB >> >> So, stopping to hibernate with mlocked memory would essentially prohibit any >> modern Linux distro to hibernate ever. > > My system seems to be completely fine without mlocked memory. It would > be interesting to see who mlocks memory on your system and check whether > the expectated mlock semantic really works for those. This should be > documented at least. I checked some other installations (Ubuntu, RHEL), and they also show no sign of Mlock. My notebook (F33) and desktop (F33) both have mlocked memory. Either related to F33 or due to some software (e.g., kerberos). -- Thanks, David / dhildenb