linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
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>
Subject: Re: [PATCH v1 10/15] mm/page-flags: reuse PG_slab as PG_anon_exclusive for PageAnon() pages
Date: Wed, 9 Mar 2022 17:57:51 +0100	[thread overview]
Message-ID: <d5b7cd5c-73eb-a1cf-5519-5d13fa6e6b00@redhat.com> (raw)
In-Reply-To: <YijL+qwc/Y1kmlnj@casper.infradead.org>

Hi,

On 09.03.22 16:47, Matthew Wilcox wrote:
> On Tue, Mar 08, 2022 at 03:14:32PM +0100, David Hildenbrand wrote:
>> The basic question we would like to have a reliable and efficient answer
>> to is: is this anonymous page exclusive to a single process or might it
>> be shared?
> 
> Is this supposed to be for PAGE_SIZE pages as well, or is it only used
> on pages > PAGE_SIZE?

As documented, simple/ordinary PAGE_SIZE pages as well (unfortunately ,
otherwise we'd have more space :) ).

> 
>> In an ideal world, we'd have a spare pageflag. Unfortunately, pageflags
>> don't grow on trees, so we have to get a little creative for the time
>> being.
> 
> This feels a little _too_ creative to me.  There's now an implicit

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)

> ->slab_cache, which is probably OK but would need to be documented.

We'd already have false positive PageAnon() if that wasn't the case. At
least in stable_page_flags() would already indicate something wrong I
think (KPF_ANON). We'd need !PageSlab() checks at a couple of places
already if I'm not wrong.

I had a comment in there, but after the PageSlab cleanups came in, I
dropped it because my assumption was that actually nobody is really
allowed to use the lowest mapping bit for something else. We can
document that, of course.

So at least in that regard, I think this is fine.

> 
> 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 :)

> to shift to another bit ... but almost any bit will do for has_hwpoisoned.
> Or have I overlooked something?

Good question, I assume we could use another bit that's not already
defined/check on subpages of a compound page.


Overloading PG_reserved would be an alternative, however, that flag can
also indicate that the remainder of the memmap might be mostly garbage,
so it's not that good of a fit IMHO.

> 
>> @@ -920,6 +976,70 @@ extern bool is_free_buddy_page(struct page *page);
>>  
>>  __PAGEFLAG(Isolated, isolated, PF_ANY);
>>  
>> +static __always_inline bool folio_test_slab(struct folio *folio)
>> +{
>> +	return !folio_test_anon(folio) &&
>> +	       test_bit(PG_slab, folio_flags(folio, FOLIO_PF_NO_TAIL));
>> +}
>> +
>> +static __always_inline int PageSlab(struct page *page)
>> +{
>> +	return !PageAnon(page) &&
>> +		test_bit(PG_slab, &PF_NO_TAIL(page, 0)->flags);
>> +}
> 
> In case we do end up using this, this would be better implemented as
> 
> static __always_inline int PageSlab(struct page *page)
> {
> 	return folio_test_slab(page_folio(page));
> }
> 
> since PageAnon already has a page_folio() call embedded in it.

Agreed, I mainly copied the stubs and extended them.

> 
>> +static __always_inline void __SetPageSlab(struct page *page)
>> +{
>> +	VM_BUG_ON_PGFLAGS(PageAnon(page), page);
>> +	__set_bit(PG_slab, &PF_NO_TAIL(page, 1)->flags);
>> +}
> 
> There's only one caller of __SetPageSlab() left, in kfence.  And that
> code looks ... weird.
> 
>         for (i = 0; i < KFENCE_POOL_SIZE / PAGE_SIZE; i++) {
>                 if (!i || (i % 2))
>                         continue;
> 
>                 /* Verify we do not have a compound head page. */
>                 if (WARN_ON(compound_head(&pages[i]) != &pages[i]))
>                         goto err;
> 
>                 __SetPageSlab(&pages[i]);
> 
> I think the author probably intended WARN_ON(PageCompound(page)) because
> they're actually verifying that it's not a tail page, rather than head
> page.

It's certainly a head-scratcher.

> 
>> +static __always_inline void __ClearPageSlab(struct page *page)
>> +{
>> +	VM_BUG_ON_PGFLAGS(PageAnon(page), page);
>> +	__clear_bit(PG_slab, &PF_NO_TAIL(page, 1)->flags);
>> +}
> 
> There are no remaining callers of __ClearPageSlab().  yay.
> 

Indeed, nice.

Thanks!

-- 
Thanks,

David / dhildenb



  reply	other threads:[~2022-03-09 16:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 14:14 [PATCH v1 00/15] mm: COW fixes part 2: reliable GUP pins of anonymous pages David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 01/15] mm/rmap: fix missing swap_free() in try_to_unmap() after arch_unmap_one() failed David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 02/15] mm/hugetlb: take src_mm->write_protect_seq in copy_hugetlb_page_range() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 03/15] mm/memory: slightly simplify copy_present_pte() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 04/15] mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 05/15] mm/rmap: convert RMAP flags to a proper distinct rmap_t type David Hildenbrand
2022-03-08 17:15   ` Nadav Amit
2022-03-08 17:30     ` David Hildenbrand
2022-03-08 18:09     ` Linus Torvalds
2022-03-08 18:24       ` Nadav Amit
2022-03-08 18:42         ` Linus Torvalds
2022-03-08 14:14 ` [PATCH v1 06/15] mm/rmap: remove do_page_add_anon_rmap() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 07/15] mm/rmap: pass rmap flags to hugepage_add_anon_rmap() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 08/15] mm/rmap: drop "compound" parameter from page_add_new_anon_rmap() David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 09/15] mm/rmap: use page_move_anon_rmap() when reusing a mapped PageAnon() page exclusively David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 10/15] mm/page-flags: reuse PG_slab as PG_anon_exclusive for PageAnon() pages David Hildenbrand
2022-03-09 15:47   ` Matthew Wilcox
2022-03-09 16:57     ` David Hildenbrand [this message]
2022-03-09 17:40       ` Matthew Wilcox
2022-03-09 18:00         ` David Hildenbrand
2022-03-11 18:46   ` David Hildenbrand
     [not found]     ` <CAHk-=wjWx_bPBLB=qMMae8Sy3KrO+Kvaf4juPknO5HX-+Ot0XQ@mail.gmail.com>
2022-03-11 19:36       ` David Hildenbrand
2022-03-11 21:11         ` Matthew Wilcox
2022-03-12  8:11           ` David Hildenbrand
2022-03-11 21:02     ` Matthew Wilcox
2022-03-12  8:26       ` David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 11/15] mm: remember exclusively mapped anonymous pages with PG_anon_exclusive David Hildenbrand
2022-03-11 18:52   ` David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 12/15] mm/gup: disallow follow_page(FOLL_PIN) David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 13/15] mm: support GUP-triggered unsharing of anonymous pages David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 14/15] mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page David Hildenbrand
2022-03-08 14:14 ` [PATCH v1 15/15] mm/gup: sanity-check with CONFIG_DEBUG_VM that anonymous pages are exclusive when (un)pinning David Hildenbrand
2022-03-08 14:19 ` [PATCH v1 00/15] mm: COW fixes part 2: reliable GUP pins of anonymous pages David Hildenbrand
2022-03-08 21:22 ` Linus Torvalds
2022-03-09  8:00   ` David Hildenbrand
2022-03-10 11:13     ` Oded Gabbay
2022-03-10 11:57       ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5b7cd5c-73eb-a1cf-5519-5d13fa6e6b00@redhat.com \
    --to=david@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ddutile@redhat.com \
    --cc=glider@google.com \
    --cc=guro@fb.com \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=namit@vmware.com \
    --cc=oded.gabbay@gmail.com \
    --cc=oleg@redhat.com \
    --cc=pedrodemargomes@gmail.com \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=rppt@linux.ibm.com \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=zhangliang5@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox