Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <32c4bd91-08cf-7318-02b7-f43452447aef@redhat.com>
Date:   Wed, 9 Mar 2022 19:00:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Language: en-US
To:     Matthew Wilcox <willy@infradead.org>
Cc:     linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Hugh Dickins <hughd@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        David Rientjes <rientjes@google.com>,
        Shakeel Butt <shakeelb@google.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Jason Gunthorpe <jgg@nvidia.com>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Yang Shi <shy828301@gmail.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
        Michal Hocko <mhocko@kernel.org>,
        Nadav Amit <namit@vmware.com>, Rik van Riel <riel@surriel.com>,
        Roman Gushchin <guro@fb.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Peter Xu <peterx@redhat.com>,
        Donald Dutile <ddutile@redhat.com>,
        Christoph Hellwig <hch@lst.de>,
        Oleg Nesterov <oleg@redhat.com>, Jan Kara <jack@suse.cz>,
        Liang Zhang <zhangliang5@huawei.com>,
        Pedro Gomes <pedrodemargomes@gmail.com>,
        Oded Gabbay <oded.gabbay@gmail.com>, linux-mm@kvack.org,
        Alexander Potapenko <glider@google.com>
References: <20220308141437.144919-1-david@redhat.com>
 <20220308141437.144919-11-david@redhat.com>
 <YijL+qwc/Y1kmlnj@casper.infradead.org>
 <d5b7cd5c-73eb-a1cf-5519-5d13fa6e6b00@redhat.com>
 <YijmoncSWx/XWkOW@casper.infradead.org>
From:   David Hildenbrand <david@redhat.com>
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: <YijmoncSWx/XWkOW@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

>> It's making the semantics of PG_slab depend on another bit in the head
>> page. I agree, it's not perfect, but it's not *too* crazy. As raised in
>> the cover letter, not proud of this, but I didn't really find an
>> alternative for the time being.
>>
>>> requirement that SL[AOU]B doesn't use the bottom two bits of
>>
>> I think only the last bit (0x1)
> 
> Yeah, OK, they can use three of the four possible combinations of the
> bottom two bits ;-)  Still, it's yet more constraints on use of struct
> page, which aren't obvious (and are even upside down for the casual
> observer).

I don't disagree that such constraints are nasty.

Having that said, I'd really like to avoid overloading PG_slab
(especially, such that I don't have to mess with
scripts/crash/makedumpfile). So if we can reuse MappedToDisk, that would
be very nice.

> 
>>> I have plans to get rid of PageError and PagePrivate, but those are going
>>> to be too late for you.  I don't think mappedtodisk has meaning for anon
>>> pages, even if they're in the swapcache.  It would need PG_has_hwpoisoned
>>
>> Are you sure it's not used if the page is in the swapcache? I have no
>> detailed knowledge how file-back swap targets are handled in that
>> regard. So fs experience would be highly appreciated :)
> 
> I have two arguments here.  One is based on grep:
> 
> $ git grep mappedtodisk
> fs/proc/page.c: u |= kpf_copy_bit(k, KPF_MAPPEDTODISK,  PG_mappedtodisk);
> include/linux/page-flags.h:     PG_mappedtodisk,        /* Has blocks allocated on-disk */
> include/linux/page-flags.h:     PG_has_hwpoisoned = PG_mappedtodisk,
> include/linux/page-flags.h:PAGEFLAG(MappedToDisk, mappedtodisk, PF_NO_TAIL)
> include/trace/events/mmflags.h: {1UL << PG_mappedtodisk,        "mappedtodisk"  },              \
> include/trace/events/pagemap.h: (folio_test_mappedtodisk(folio) ? PAGEMAP_MAPPEDDISK : 0) | \
> mm/migrate.c:   if (folio_test_mappedtodisk(folio))
> mm/migrate.c:           folio_set_mappedtodisk(newfolio);
> mm/truncate.c:  folio_clear_mappedtodisk(folio);
> tools/vm/page-types.c:  [KPF_MAPPEDTODISK]      = "d:mappedtodisk",
> 
> $ git grep MappedToDisk
> fs/buffer.c:            SetPageMappedToDisk(page);
> fs/buffer.c:    if (PageMappedToDisk(page))
> fs/buffer.c:            SetPageMappedToDisk(page);
> fs/ext4/readpage.c:                     SetPageMappedToDisk(page);
> fs/f2fs/data.c:         SetPageMappedToDisk(page);
> fs/f2fs/file.c: if (PageMappedToDisk(page))
> fs/fuse/dev.c:  ClearPageMappedToDisk(newpage);
> fs/mpage.c:             SetPageMappedToDisk(page);
> fs/nilfs2/file.c:       if (PageMappedToDisk(page))
> fs/nilfs2/file.c:                       SetPageMappedToDisk(page);
> fs/nilfs2/page.c:       ClearPageMappedToDisk(page);
> fs/nilfs2/page.c:               SetPageMappedToDisk(dpage);
> fs/nilfs2/page.c:               ClearPageMappedToDisk(dpage);
> fs/nilfs2/page.c:       if (PageMappedToDisk(src) && !PageMappedToDisk(dst))
> fs/nilfs2/page.c:               SetPageMappedToDisk(dst);
> fs/nilfs2/page.c:       else if (!PageMappedToDisk(src) && PageMappedToDisk(dst))
> fs/nilfs2/page.c:               ClearPageMappedToDisk(dst);
> fs/nilfs2/page.c:       ClearPageMappedToDisk(page);
> include/linux/page-flags.h:PAGEFLAG(MappedToDisk, mappedtodisk, PF_NO_TAIL)
> 
> so you can see it's _rarely_ used, and only by specific filesystems.

Right, but I spot ext4 and fs/buffer.c core functionality. That
naturally makes me nervous :)

> 
> The swap code actually bypasses the filesystem (except for network
> filesystems) and submits BIOs directly (see __swap_writepage() and
> swap_readpage()).  There's no check for MappedToDisk, and nowhere to
> set it/clear it.
> 
> The second argument is that MappedToDisk is used for delayed allocation
> on writes for filesystems.  But swap is required to be allocated at
> swapfile setup (so that the swap code can bypass the filesystem ...)
> and so this flag is useless.

I have some faint memory that there are corner cases, but maybe
(hopefully) my memory is wrong.

> 
> Of course, I may have missed something.  This is complex.
> 

Yeah, that's why I was very careful. If any FS would end up setting that
flag we'd be in trouble and would have to blacklist that fs for swapping
or rework it (well, if we're even able to identify such a file system).

I think one sanity check I could add is making sure that
PageAnonExclusive() is never set when getting a page from the swapcache
in do_swap_page(). I think that would take care of the obvious bugs.

-- 
Thanks,

David / dhildenb