All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>,
	intel-gfx@lists.freedesktop.org, Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org,
	Chris Wilson <chris@chris-wilson.co.uk>,
	linux-mm@kvack.org, Matthew Auld <matthew.auld@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	cgroups@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH 6/8] mm: Convert find_get_entry to return the head page
Date: Wed, 26 Aug 2020 11:09:25 -0400	[thread overview]
Message-ID: <20200826150925.GE988805@cmpxchg.org> (raw)
In-Reply-To: <20200819184850.24779-7-willy@infradead.org>

On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> There are only three callers remaining of find_get_entry().
> find_get_swap_page() is happy to get the head page instead of the subpage.
> Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
> to avoid auditing all their callers.

I believe this would cause a subtle bug in memcg charge moving for pte
mapped huge pages. We currently skip over tail pages in the range
(they don't have page->mem_cgroup set) and account for the huge page
once from the headpage. After this change, we would see the headpage
and account for it 512 times (or whatever the number is on non-x86).

But that aside, I don't quite understand the intent.

Before, all these functions simply return the base page at @index,
whether it's a regular page or a tail page.

Afterwards, find_lock_entry(), find_get_page() et al still do, but
find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK.

Shouldn't we be consistent about how we handle huge pages when
somebody queries the tree for a given base page index?

[ Wouldn't that mean that e.g. find_get_swap_page() would return tail
  pages for regular files and head pages for shmem files? ]

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>,
	intel-gfx@lists.freedesktop.org, Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org,
	Chris Wilson <chris@chris-wilson.co.uk>,
	linux-mm@kvack.org, Matthew Auld <matthew.auld@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	cgroups@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [Intel-gfx] [PATCH 6/8] mm: Convert find_get_entry to return the head page
Date: Wed, 26 Aug 2020 11:09:25 -0400	[thread overview]
Message-ID: <20200826150925.GE988805@cmpxchg.org> (raw)
In-Reply-To: <20200819184850.24779-7-willy@infradead.org>

On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> There are only three callers remaining of find_get_entry().
> find_get_swap_page() is happy to get the head page instead of the subpage.
> Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
> to avoid auditing all their callers.

I believe this would cause a subtle bug in memcg charge moving for pte
mapped huge pages. We currently skip over tail pages in the range
(they don't have page->mem_cgroup set) and account for the huge page
once from the headpage. After this change, we would see the headpage
and account for it 512 times (or whatever the number is on non-x86).

But that aside, I don't quite understand the intent.

Before, all these functions simply return the base page at @index,
whether it's a regular page or a tail page.

Afterwards, find_lock_entry(), find_get_page() et al still do, but
find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK.

Shouldn't we be consistent about how we handle huge pages when
somebody queries the tree for a given base page index?

[ Wouldn't that mean that e.g. find_get_swap_page() would return tail
  pages for regular files and head pages for shmem files? ]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	William Kucharski <william.kucharski@oracle.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Matthew Auld <matthew.auld@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	intel-gfx@lists.freedesktop.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] mm: Convert find_get_entry to return the head page
Date: Wed, 26 Aug 2020 11:09:25 -0400	[thread overview]
Message-ID: <20200826150925.GE988805@cmpxchg.org> (raw)
In-Reply-To: <20200819184850.24779-7-willy@infradead.org>

On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote:
> There are only three callers remaining of find_get_entry().
> find_get_swap_page() is happy to get the head page instead of the subpage.
> Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
> to avoid auditing all their callers.

I believe this would cause a subtle bug in memcg charge moving for pte
mapped huge pages. We currently skip over tail pages in the range
(they don't have page->mem_cgroup set) and account for the huge page
once from the headpage. After this change, we would see the headpage
and account for it 512 times (or whatever the number is on non-x86).

But that aside, I don't quite understand the intent.

Before, all these functions simply return the base page at @index,
whether it's a regular page or a tail page.

Afterwards, find_lock_entry(), find_get_page() et al still do, but
find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK.

Shouldn't we be consistent about how we handle huge pages when
somebody queries the tree for a given base page index?

[ Wouldn't that mean that e.g. find_get_swap_page() would return tail
  pages for regular files and head pages for shmem files? ]


  reply	other threads:[~2020-08-26 15:09 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 18:48 [PATCH 0/8] Return head pages from find_get_entry and find_lock_entry Matthew Wilcox (Oracle)
2020-08-19 18:48 ` Matthew Wilcox (Oracle)
2020-08-19 18:48 ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-19 18:48 ` [PATCH 1/8] mm: Factor find_get_swap_page out of mincore_page Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-19 19:21   ` Matthew Wilcox
2020-08-19 19:21     ` Matthew Wilcox
2020-08-19 19:21     ` [Intel-gfx] " Matthew Wilcox
2020-08-19 18:48 ` [PATCH 2/8] mm: Use find_get_swap_page in memcontrol Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-26 14:20   ` Johannes Weiner
2020-08-26 14:20     ` Johannes Weiner
2020-08-26 14:20     ` [Intel-gfx] " Johannes Weiner
2020-08-26 14:54     ` Matthew Wilcox
2020-08-26 14:54       ` Matthew Wilcox
2020-08-26 14:54       ` [Intel-gfx] " Matthew Wilcox
2020-08-26 16:26       ` Johannes Weiner
2020-08-26 16:26         ` Johannes Weiner
2020-08-26 16:26         ` [Intel-gfx] " Johannes Weiner
2020-08-27 12:59     ` Matthew Wilcox
2020-08-27 12:59       ` Matthew Wilcox
2020-08-27 12:59       ` [Intel-gfx] " Matthew Wilcox
2020-08-27 14:22       ` Johannes Weiner
2020-08-27 14:22         ` Johannes Weiner
2020-08-27 14:22         ` [Intel-gfx] " Johannes Weiner
     [not found] ` <20200819184850.24779-1-willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2020-08-19 18:48   ` [PATCH 3/8] mm: Optimise madvise WILLNEED Matthew Wilcox (Oracle)
2020-08-19 18:48     ` Matthew Wilcox (Oracle)
2020-08-19 18:48     ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-26 14:23     ` Johannes Weiner
2020-08-26 14:23       ` Johannes Weiner
2020-08-26 14:23       ` [Intel-gfx] " Johannes Weiner
2020-08-21 17:37   ` [PATCH 0/8] Return head pages from find_get_entry and find_lock_entry William Kucharski
2020-08-21 17:37     ` William Kucharski
2020-08-21 17:37     ` [Intel-gfx] " William Kucharski
2020-08-19 18:48 ` [PATCH 4/8] proc: Optimise smaps for shmem entries Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-26 14:24   ` Johannes Weiner
2020-08-26 14:24     ` Johannes Weiner
2020-08-26 14:24     ` [Intel-gfx] " Johannes Weiner
2020-08-19 18:48 ` [PATCH 5/8] i915: Use find_lock_page instead of find_lock_entry Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-26 14:27   ` Johannes Weiner
2020-08-26 14:27     ` Johannes Weiner
2020-08-26 14:27     ` [Intel-gfx] " Johannes Weiner
2020-08-19 18:48 ` [PATCH 6/8] mm: Convert find_get_entry to return the head page Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-26 15:09   ` Johannes Weiner [this message]
2020-08-26 15:09     ` Johannes Weiner
2020-08-26 15:09     ` [Intel-gfx] " Johannes Weiner
2020-08-26 15:48     ` Matthew Wilcox
2020-08-26 15:48       ` Matthew Wilcox
2020-08-26 15:48       ` [Intel-gfx] " Matthew Wilcox
2020-08-19 18:48 ` [PATCH 7/8] mm: Return head page from find_lock_entry Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-19 18:48 ` [PATCH 8/8] mm: Hoist find_subpage call further up in pagecache_get_page Matthew Wilcox (Oracle)
2020-08-19 18:48   ` Matthew Wilcox (Oracle)
2020-08-19 18:48   ` [Intel-gfx] " Matthew Wilcox (Oracle)
2020-08-19 19:06 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Return head pages from find_get_entry and find_lock_entry Patchwork
2020-08-19 19:16   ` Matthew Wilcox
2020-08-19 19:22   ` Matthew Wilcox
2020-08-19 19:29 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Return head pages from find_get_entry and find_lock_entry (rev2) Patchwork
2020-08-20  1:29   ` Matthew Wilcox

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=20200826150925.GE988805@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=hughd@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.auld@intel.com \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.