From: Jason Gunthorpe <jgg@ziepe.ca>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com,
david@redhat.com, osalvador@suse.de, dan.j.williams@intel.com,
sashal@kernel.org, tyhicks@linux.microsoft.com,
iamjoonsoo.kim@lge.com, mike.kravetz@oracle.com,
rostedt@goodmis.org, mingo@redhat.com, peterz@infradead.org,
mgorman@suse.de, willy@infradead.org, rientjes@google.com,
jhubbard@nvidia.com, linux-doc@vger.kernel.org,
ira.weiny@intel.com, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 08/10] mm/gup: limit number of gup migration failures, honor failures
Date: Thu, 17 Dec 2020 16:50:48 -0400 [thread overview]
Message-ID: <20201217205048.GL5487@ziepe.ca> (raw)
In-Reply-To: <20201217185243.3288048-9-pasha.tatashin@soleen.com>
On Thu, Dec 17, 2020 at 01:52:41PM -0500, Pavel Tatashin wrote:
> +/*
> + * Verify that there are no unpinnable (movable) pages, if so return true.
> + * Otherwise an unpinnable pages is found return false, and unpin all pages.
> + */
> +static bool check_and_unpin_pages(unsigned long nr_pages, struct page **pages,
> + unsigned int gup_flags)
> +{
> + unsigned long i, step;
> +
> + for (i = 0; i < nr_pages; i += step) {
> + struct page *head = compound_head(pages[i]);
> +
> + step = compound_nr(head) - (pages[i] - head);
You can't assume that all of a compound head is in the pages array,
this assumption would only work inside the page walkers if the page
was found in a PMD or something.
> + if (gup_flags & FOLL_PIN) {
> + unpin_user_pages(pages, nr_pages);
So we throw everything away? Why? That isn't how the old algorithm worked
> @@ -1654,22 +1664,55 @@ static long __gup_longterm_locked(struct mm_struct *mm,
> struct vm_area_struct **vmas,
> unsigned int gup_flags)
> {
> - unsigned long flags = 0;
> + int migrate_retry = 0;
> + int isolate_retry = 0;
> + unsigned int flags;
> long rc;
>
> - if (gup_flags & FOLL_LONGTERM)
> - flags = memalloc_pin_save();
> + if (!(gup_flags & FOLL_LONGTERM))
> + return __get_user_pages_locked(mm, start, nr_pages, pages, vmas,
> + NULL, gup_flags);
>
> - rc = __get_user_pages_locked(mm, start, nr_pages, pages, vmas, NULL,
> - gup_flags);
> + /*
> + * Without FOLL_WRITE fault handler may return zero page, which can
> + * be in a movable zone, and also will fail to isolate during migration,
> + * thus the longterm pin will fail.
> + */
> + gup_flags &= FOLL_WRITE;
Is &= what you mean here? |= right?
Seems like we've ended up in a weird place if FOLL_LONGTERM always
includes FOLL_WRITE. Putting the zero page in ZONE_MOVABLE seems like
a bad idea, no?
> + /*
> + * Migration may fail, we retry before giving up. Also, because after
> + * migration pages[] becomes outdated, we unpin and repin all pages
> + * in the range, so pages array is repopulated with new values.
> + * Also, because of this we cannot retry migration failures in a loop
> + * without pinning/unpinnig pages.
> + */
The old algorithm made continuous forward progress and only went back
to the first migration point.
> + for (; ; ) {
while (true)?
> + rc = __get_user_pages_locked(mm, start, nr_pages, pages, vmas,
> + NULL, gup_flags);
> + /* Return if error or if all pages are pinnable */
> + if (rc <= 0 || check_and_unpin_pages(rc, pages, gup_flags))
> + break;
So we sweep the pages list twice now?
> + /* Some pages are not pinnable, migrate them */
> + rc = migrate_movable_pages(rc, pages);
> +
> + /*
> + * If there is an error, and we tried maximum number of times
> + * bail out. Notice: we return an error code, and all pages are
> + * unpinned
> + */
> + if (rc < 0 && migrate_retry++ >= PINNABLE_MIGRATE_MAX) {
> + break;
> + } else if (rc > 0 && isolate_retry++ >= PINNABLE_ISOLATE_MAX) {
> + rc = -EBUSY;
I don't like this at all. It shouldn't be so flakey
Can you do migration without the LRU?
Jason
next prev parent reply other threads:[~2020-12-17 20:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 18:52 [PATCH v4 00/10] prohibit pinning pages in ZONE_MOVABLE Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 01/10] mm/gup: don't pin migrated cma pages in movable zone Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 02/10] mm cma: rename PF_MEMALLOC_NOCMA to PF_MEMALLOC_PIN Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 03/10] mm: apply per-task gfp constraints in fast path Pavel Tatashin
2020-12-18 9:36 ` Michal Hocko
2020-12-18 12:23 ` Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 04/10] mm: honor PF_MEMALLOC_PIN for all movable pages Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 05/10] mm/gup: migrate pinned pages out of movable zone Pavel Tatashin
2020-12-18 9:43 ` Michal Hocko
2020-12-18 12:24 ` Pavel Tatashin
2020-12-18 13:08 ` Michal Hocko
2021-01-13 19:14 ` Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 06/10] memory-hotplug.rst: add a note about ZONE_MOVABLE and page pinning Pavel Tatashin
2020-12-18 9:44 ` Michal Hocko
2020-12-17 18:52 ` [PATCH v4 07/10] mm/gup: change index type to long as it counts pages Pavel Tatashin
2020-12-18 9:50 ` Michal Hocko
2020-12-18 12:32 ` Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 08/10] mm/gup: limit number of gup migration failures, honor failures Pavel Tatashin
2020-12-17 20:50 ` Jason Gunthorpe [this message]
2020-12-17 22:02 ` Pavel Tatashin
2020-12-18 14:19 ` Jason Gunthorpe
2021-01-13 19:43 ` Pavel Tatashin
2021-01-13 19:55 ` Jason Gunthorpe
2021-01-13 20:05 ` Pavel Tatashin
2021-01-13 23:40 ` Jason Gunthorpe
2021-01-15 18:10 ` Pavel Tatashin
2021-01-15 18:40 ` Jason Gunthorpe
2020-12-18 10:46 ` Michal Hocko
2020-12-18 12:43 ` Pavel Tatashin
2020-12-18 13:04 ` David Hildenbrand
2020-12-18 13:14 ` Michal Hocko
2021-01-13 19:49 ` Pavel Tatashin
2020-12-17 18:52 ` [PATCH v4 09/10] selftests/vm: test flag is broken Pavel Tatashin
2020-12-18 9:06 ` John Hubbard
2020-12-18 9:11 ` John Hubbard
2020-12-17 18:52 ` [PATCH v4 10/10] selftests/vm: test faulting in kernel, and verify pinnable pages Pavel Tatashin
2020-12-19 5:57 ` John Hubbard
2020-12-19 15:22 ` Pavel Tatashin
2020-12-19 23:51 ` John Hubbard
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=20201217205048.GL5487@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=ira.weiny@intel.com \
--cc=jhubbard@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sashal@kernel.org \
--cc=tyhicks@linux.microsoft.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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.