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=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 6152BC04EB9 for ; Wed, 5 Dec 2018 12:59:23 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE7A32081B for ; Wed, 5 Dec 2018 12:59:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE7A32081B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 438zMW19mYzDqjW for ; Wed, 5 Dec 2018 23:59:19 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=david@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 438yk63709zDqnV for ; Wed, 5 Dec 2018 23:30:22 +1100 (AEDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B69453078A25; Wed, 5 Dec 2018 12:30:19 +0000 (UTC) Received: from t460s.redhat.com (ovpn-117-65.ams2.redhat.com [10.36.117.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C16E183D2; Wed, 5 Dec 2018 12:30:16 +0000 (UTC) From: David Hildenbrand To: linux-mm@kvack.org Subject: [PATCH RFC 7/7] mm: better document PG_reserved Date: Wed, 5 Dec 2018 13:28:51 +0100 Message-Id: <20181205122851.5891-8-david@redhat.com> In-Reply-To: <20181205122851.5891-1-david@redhat.com> References: <20181205122851.5891-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Wed, 05 Dec 2018 12:30:20 +0000 (UTC) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, Michal Hocko , Miles Chen , David Hildenbrand , Alexander Duyck , Dan Williams , linux-kernel@vger.kernel.org, Matthew Wilcox , Pavel Tatashin , yi.z.zhang@linux.intel.com, linux-m68k@lists.linux-m68k.org, linux-mediatek@lists.infradead.org, Anthony Yznaga , Stephen Rothwell , linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, Andrew Morton , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" The usage of PG_reserved and how PG_reserved pages are to be treated is burried deep down in different parts of the kernel. Let's shine some light onto these details by documenting (most?) current users and expected behavior. I don't see a reason why we have to document "Some of them might not even exist". If there is a user, we should document it. E.g. for balloon drivers we now use PG_offline to indicate that a page might currently not be backed by memory in the hypervisor. And that is independent from PG_reserved. Cc: Andrew Morton Cc: Stephen Rothwell Cc: Pavel Tatashin Cc: Michal Hocko Cc: Alexander Duyck Cc: Matthew Wilcox Cc: Anthony Yznaga Cc: Miles Chen Cc: yi.z.zhang@linux.intel.com Cc: Dan Williams Signed-off-by: David Hildenbrand --- include/linux/page-flags.h | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 68b8495e2fbc..112526f5ba61 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -17,8 +17,22 @@ /* * Various page->flags bits: * - * PG_reserved is set for special pages, which can never be swapped out. Some - * of them might not even exist... + * PG_reserved is set for special pages. The "struct page" of such a page + * should in general not be touched (e.g. set dirty) except by their owner. + * Pages marked as PG_reserved include: + * - Kernel image (including vDSO) and similar (e.g. BIOS, initrd) + * - Pages allocated early during boot (bootmem, memblock) + * - Zero pages + * - Pages that have been associated with a zone but are not available for + * the page allocator (e.g. excluded via online_page_callback()) + * - Pages to exclude from the hibernation image (e.g. loaded kexec images) + * - MMIO pages (communicate with a device, special caching strategy needed) + * - MCA pages on ia64 (pages with memory errors) + * - Device memory (e.g. PMEM, DAX, HMM) + * Some architectures don't allow to ioremap pages that are not marked + * PG_reserved (as they might be in use by somebody else who does not respect + * the caching strategy). Consequently, PG_reserved for a page mapped into + * user space can indicate the zero page, the vDSO, MMIO pages or device memory. * * The PG_private bitflag is set on pagecache pages if they contain filesystem * specific data (which is normally at page->private). It can be used by -- 2.17.2