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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EDA0C433EF for ; Sat, 12 Mar 2022 08:26:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DE818D0002; Sat, 12 Mar 2022 03:26:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28E118D0001; Sat, 12 Mar 2022 03:26:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12E548D0002; Sat, 12 Mar 2022 03:26:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 03EB68D0001 for ; Sat, 12 Mar 2022 03:26:52 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A84AA7D8A5 for ; Sat, 12 Mar 2022 08:26:51 +0000 (UTC) X-FDA: 79235053422.30.C71C6A2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 2830140022 for ; Sat, 12 Mar 2022 08:26:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1647073610; 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=bOmlxQFnd+zuYEnurfNJceNYzy+E5RZ8J3vmwLJAIl0=; b=AP7S5dZVXmOAY1+pNdVzF5NfT3IMMo5bjg4IWA6+BAFIp3PmGOrfLQv/PSqsgYw6zYqGeD 7T5aHZNDREYEpfZuM6jD96eOwdThYYiZD1SWCrStDOe4uU5ssHzfea0OOF7lMvUGiJ2220 SW+rwzr5Gig99OCII8b7CKC1309ezBA= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-107-ud3pb0xCMkW3_6zGiGRtOQ-1; Sat, 12 Mar 2022 03:26:49 -0500 X-MC-Unique: ud3pb0xCMkW3_6zGiGRtOQ-1 Received: by mail-wm1-f69.google.com with SMTP id c62-20020a1c3541000000b003815245c642so6563461wma.6 for ; Sat, 12 Mar 2022 00:26:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=bOmlxQFnd+zuYEnurfNJceNYzy+E5RZ8J3vmwLJAIl0=; b=GutvaODKNgCpBmPCZqSUnCPwZ2jEq1aElcqXeLNoqBwnS4lF7mk2jHZJulcrAOf4Kr 2VZieX19pyD9BgTiE2F7lOr68qK+/1y+O60wHGY8ZWpURa1T3U1KazbojmT+SLW9leUB +6hbwZkLeubb9gQs0d7iYSUFVBCJqx09tFxlokUXFLra4676A4b4TXigpVgcxVlgZHoG he/Efec9SGnpiaHc3OGBV2JtJeP9qK2bokzDCnHUIGj0kJluU/s/K1QH6rcH16s3cpVs +D1aXw4GMoqY4DLVsRILY+tZPzf7KTibqpAGTWkP7BZ1JreWuscCJDCzLpGEH9Pxtssx tl9g== X-Gm-Message-State: AOAM530d76/AMJnfe88dJIV+g+W8UqcaDrB7FFABL/9Yt7u0jAR7H7Sj DUIk0JJkVh8JTD6XW2Ul29Y8vNob90czwcxSfzR7P62tMzi61klVR1KQ6L0RvIo7zJ6uajj6nkn OUpo7ywquzNU= X-Received: by 2002:adf:fb4e:0:b0:1e3:3e66:d5f6 with SMTP id c14-20020adffb4e000000b001e33e66d5f6mr10234167wrs.615.1647073608155; Sat, 12 Mar 2022 00:26:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6pCNrzBS5gHuwSLg45uz9evRExxAsiY3uVCgQXVOVBmSNztNJlOD1/5qe+WlsOx00+9Y93w== X-Received: by 2002:adf:fb4e:0:b0:1e3:3e66:d5f6 with SMTP id c14-20020adffb4e000000b001e33e66d5f6mr10234131wrs.615.1647073607842; Sat, 12 Mar 2022 00:26:47 -0800 (PST) Received: from ?IPV6:2003:cb:c71e:1600:ad89:c64e:8371:c9c4? (p200300cbc71e1600ad89c64e8371c9c4.dip0.t-ipconnect.de. [2003:cb:c71e:1600:ad89:c64e:8371:c9c4]) by smtp.gmail.com with ESMTPSA id f22-20020a1cc916000000b00380d3e49e89sm8808771wmb.22.2022.03.12.00.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Mar 2022 00:26:47 -0800 (PST) Message-ID: <2bbe2f37-37af-664d-181f-034917b6bb93@redhat.com> Date: Sat, 12 Mar 2022 09:26:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org References: <20220308141437.144919-1-david@redhat.com> <20220308141437.144919-11-david@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1 10/15] mm/page-flags: reuse PG_slab as PG_anon_exclusive for PageAnon() pages In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 2830140022 X-Stat-Signature: z4mc8gtyxbbbxboydm5sqfu7rcdbw6ef Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AP7S5dZV; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf27.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1647073610-96320 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11.03.22 22:02, Matthew Wilcox wrote: > On Fri, Mar 11, 2022 at 07:46:39PM +0100, David Hildenbrand wrote: >> I'm currently testing with the following. My tests so far with a swapfile on >> all different kinds of weird filesystems (excluding networking fs, though) >> revealed no surprises so far: > > I like this a lot better than reusing PG_swap. Thanks! > > I'm somewhat reluctant to introduce a new flag that can be set on tail > pages. Do we lose much if it's always set only on the head page? After spending one month on getting THP to work without PF_ANY, I can say with confidence that the whole thing won't fly with THP when not tracking it on the minimum-mapping granularity. For a PTE-mapped THP, that's on the subpage level. The next patch in the series documents some details. Intuitively, if we could replace the pageflag by a PTE/PMD bit, we'd get roughly the same result. > >> +++ b/include/linux/page-flags.h >> @@ -142,6 +142,60 @@ enum pageflags { >> >> PG_readahead = PG_reclaim, >> >> + /* >> + * Depending on the way an anonymous folio can be mapped into a page >> + * table (e.g., single PMD/PUD/CONT of the head page vs. PTE-mapped >> + * THP), PG_anon_exclusive may be set only for the head page or for >> + * subpages of an anonymous folio. >> + * >> + * PG_anon_exclusive is *usually* only expressive in combination with a >> + * page table entry. Depending on the page table entry type it might >> + * store the following information: >> + * >> + * Is what's mapped via this page table entry exclusive to the >> + * single process and can be mapped writable without further >> + * checks? If not, it might be shared and we might have to COW. >> + * >> + * For now, we only expect PTE-mapped THPs to make use of >> + * PG_anon_exclusive in subpages. For other anonymous compound >> + * folios (i.e., hugetlb), only the head page is logically mapped and >> + * holds this information. >> + * >> + * For example, an exclusive, PMD-mapped THP only has PG_anon_exclusive >> + * set on the head page. When replacing the PMD by a page table full >> + * of PTEs, PG_anon_exclusive, if set on the head page, will be set on >> + * all tail pages accordingly. Note that converting from a PTE-mapping >> + * to a PMD mapping using the same compound page is currently not >> + * possible and consequently doesn't require care. >> + * >> + * If GUP wants to take a reliable pin (FOLL_PIN) on an anonymous page, >> + * it should only pin if the relevant PG_anon_bit is set. In that case, >> + * the pin will be fully reliable and stay consistent with the pages >> + * mapped into the page table, as the bit cannot get cleared (e.g., by >> + * fork(), KSM) while the page is pinned. For anonymous pages that >> + * are mapped R/W, PG_anon_exclusive can be assumed to always be set >> + * because such pages cannot possibly be shared. >> + * >> + * The page table lock protecting the page table entry is the primary >> + * synchronization mechanism for PG_anon_exclusive; GUP-fast that does >> + * not take the PT lock needs special care when trying to clear the >> + * flag. >> + * >> + * Page table entry types and PG_anon_exclusive: >> + * * Present: PG_anon_exclusive applies. >> + * * Swap: the information is lost. PG_anon_exclusive was cleared. >> + * * Migration: the entry holds this information instead. >> + * PG_anon_exclusive was cleared. >> + * * Device private: PG_anon_exclusive applies. >> + * * Device exclusive: PG_anon_exclusive applies. >> + * * HW Poison: PG_anon_exclusive is stale and not changed. >> + * >> + * If the page may be pinned (FOLL_PIN), clearing PG_anon_exclusive is >> + * not allowed and the flag will stick around until the page is freed >> + * and folio->mapping is cleared. >> + */ > > ... I also don't think this is the right place for this comment. Not > sure where it should go. I went for "rather have some documentation at a sub-optimal place then no documentation at all". I'm thinking about writing a proper documentation once everything is in place, and moving some details from there into that document then. > >> +static __always_inline void SetPageAnonExclusive(struct page *page) >> +{ >> + VM_BUG_ON_PGFLAGS(!PageAnon(page) || PageKsm(page), page); > > hm. seems to me like we should have a PageAnonNotKsm which just > does > return ((unsigned long)page->mapping & PAGE_MAPPING_FLAGS) == > PAGE_MAPPING_ANON; > because that's "a bit" inefficient. OK, that's just a VM_BUG_ON, > but we have other users in real code: > > mm/migrate.c: if (PageAnon(page) && !PageKsm(page)) > mm/page_idle.c: need_lock = !PageAnon(page) || PageKsm(page); > mm/rmap.c: if (!is_locked && (!PageAnon(page) || PageKsm(page))) { > I'm wondering if the compiler won't be able to optimize that. Having that said, I can look into adding that outside of this series. Thanks! -- Thanks, David / dhildenb