From: Oscar Salvador <osalvador@suse.de>
To: Zi Yan <ziy@nvidia.com>
Cc: Mel Gorman <mgorman@techsingularity.net>,
David Hildenbrand <david@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
iommu@lists.linux-foundation.org,
Eric Ren <renzhengeek@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
Date: Wed, 2 Feb 2022 13:18:54 +0100 [thread overview]
Message-ID: <Yfp2rv0K6d3cNmwg@localhost.localdomain> (raw)
In-Reply-To: <20220119190623.1029355-4-zi.yan@sent.com>
On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> Enable set_migratetype_isolate() to check specified sub-range for
> unmovable pages during isolation. Page isolation is done
> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
> pages within that granularity are intended to be isolated. For example,
> alloc_contig_range(), which uses page isolation, allows ranges without
> alignment. This commit makes unmovable page check only look for
> interesting pages, so that page isolation can succeed for any
> non-overlapping ranges.
Another thing that came to my mind.
Prior to this patch, has_unmovable_pages() was checking on pageblock
granularity, starting at pfn#0 of the pageblock.
With this patch, you no longer check on pageblock granularity, which
means you might isolate a pageblock, but some pages that sneaked in
might actually be unmovable.
E.g:
Let's say you have a pageblock that spans (pfn#512,pfn#1024),
and you pass alloc_contig_range() (pfn#514,pfn#1024).
has_unmovable_pages() will start checking the pageblock at pfn#514,
and so it will mis pfn#512 and pfn#513. Isn't that a problem, if those
pfn turn out to be actually unmovable?
--
Oscar Salvador
SUSE Labs
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Oscar Salvador <osalvador@suse.de>
To: Zi Yan <ziy@nvidia.com>
Cc: Mel Gorman <mgorman@techsingularity.net>,
David Hildenbrand <david@redhat.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
iommu@lists.linux-foundation.org,
Eric Ren <renzhengeek@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>, Vlastimil Babka <vbabka@suse.cz>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
Date: Wed, 2 Feb 2022 13:18:54 +0100 [thread overview]
Message-ID: <Yfp2rv0K6d3cNmwg@localhost.localdomain> (raw)
In-Reply-To: <20220119190623.1029355-4-zi.yan@sent.com>
On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> Enable set_migratetype_isolate() to check specified sub-range for
> unmovable pages during isolation. Page isolation is done
> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
> pages within that granularity are intended to be isolated. For example,
> alloc_contig_range(), which uses page isolation, allows ranges without
> alignment. This commit makes unmovable page check only look for
> interesting pages, so that page isolation can succeed for any
> non-overlapping ranges.
Another thing that came to my mind.
Prior to this patch, has_unmovable_pages() was checking on pageblock
granularity, starting at pfn#0 of the pageblock.
With this patch, you no longer check on pageblock granularity, which
means you might isolate a pageblock, but some pages that sneaked in
might actually be unmovable.
E.g:
Let's say you have a pageblock that spans (pfn#512,pfn#1024),
and you pass alloc_contig_range() (pfn#514,pfn#1024).
has_unmovable_pages() will start checking the pageblock at pfn#514,
and so it will mis pfn#512 and pfn#513. Isn't that a problem, if those
pfn turn out to be actually unmovable?
--
Oscar Salvador
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Oscar Salvador <osalvador@suse.de>
To: Zi Yan <ziy@nvidia.com>
Cc: David Hildenbrand <david@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
linuxppc-dev@lists.ozlabs.org,
virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>,
Eric Ren <renzhengeek@gmail.com>
Subject: Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
Date: Wed, 2 Feb 2022 13:18:54 +0100 [thread overview]
Message-ID: <Yfp2rv0K6d3cNmwg@localhost.localdomain> (raw)
In-Reply-To: <20220119190623.1029355-4-zi.yan@sent.com>
On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> Enable set_migratetype_isolate() to check specified sub-range for
> unmovable pages during isolation. Page isolation is done
> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
> pages within that granularity are intended to be isolated. For example,
> alloc_contig_range(), which uses page isolation, allows ranges without
> alignment. This commit makes unmovable page check only look for
> interesting pages, so that page isolation can succeed for any
> non-overlapping ranges.
Another thing that came to my mind.
Prior to this patch, has_unmovable_pages() was checking on pageblock
granularity, starting at pfn#0 of the pageblock.
With this patch, you no longer check on pageblock granularity, which
means you might isolate a pageblock, but some pages that sneaked in
might actually be unmovable.
E.g:
Let's say you have a pageblock that spans (pfn#512,pfn#1024),
and you pass alloc_contig_range() (pfn#514,pfn#1024).
has_unmovable_pages() will start checking the pageblock at pfn#514,
and so it will mis pfn#512 and pfn#513. Isn't that a problem, if those
pfn turn out to be actually unmovable?
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2022-02-02 12:19 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-19 19:06 [PATCH v4 0/7] Use pageblock_order for cma and alloc_contig_range alignment Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` [PATCH v4 1/7] mm: page_alloc: avoid merging non-fallbackable pageblocks with others Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-24 14:02 ` Mel Gorman
2022-01-24 14:02 ` Mel Gorman
2022-01-24 14:02 ` Mel Gorman
2022-01-24 14:02 ` Mel Gorman
2022-01-24 16:12 ` Zi Yan via iommu
2022-01-24 16:12 ` Zi Yan
2022-01-24 16:12 ` Zi Yan
2022-01-24 16:43 ` Mel Gorman
2022-01-24 16:43 ` Mel Gorman
2022-01-24 16:43 ` Mel Gorman
2022-01-24 16:43 ` Mel Gorman
2022-01-19 19:06 ` [PATCH v4 2/7] mm: page_isolation: move has_unmovable_pages() to mm/page_isolation.c Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-25 6:23 ` Oscar Salvador
2022-01-25 6:23 ` Oscar Salvador
2022-01-25 6:23 ` Oscar Salvador
2022-01-19 19:06 ` [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-24 9:55 ` Oscar Salvador
2022-01-24 9:55 ` Oscar Salvador
2022-01-24 9:55 ` Oscar Salvador
2022-01-24 17:17 ` Zi Yan via iommu
2022-01-24 17:17 ` Zi Yan
2022-01-24 17:17 ` Zi Yan
2022-01-25 13:19 ` Oscar Salvador
2022-01-25 13:19 ` Oscar Salvador
2022-01-25 13:19 ` Oscar Salvador
2022-01-25 13:21 ` Oscar Salvador
2022-01-25 13:21 ` Oscar Salvador
2022-01-25 13:21 ` Oscar Salvador
2022-01-25 16:31 ` Zi Yan via iommu
2022-01-25 16:31 ` Zi Yan
2022-01-25 16:31 ` Zi Yan
2022-02-02 12:18 ` Oscar Salvador [this message]
2022-02-02 12:18 ` Oscar Salvador
2022-02-02 12:18 ` Oscar Salvador
2022-02-02 12:25 ` David Hildenbrand
2022-02-02 12:25 ` David Hildenbrand
2022-02-02 12:25 ` David Hildenbrand
2022-02-02 12:25 ` David Hildenbrand
2022-02-02 16:25 ` Zi Yan via iommu
2022-02-02 16:25 ` Zi Yan
2022-02-02 16:25 ` Zi Yan
2022-02-02 16:35 ` Oscar Salvador
2022-02-02 16:35 ` Oscar Salvador
2022-02-02 16:35 ` Oscar Salvador
2022-01-19 19:06 ` [PATCH v4 4/7] mm: make alloc_contig_range work at pageblock granularity Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-02-04 13:56 ` Oscar Salvador
2022-02-04 13:56 ` Oscar Salvador
2022-02-04 13:56 ` Oscar Salvador
2022-02-04 15:19 ` Zi Yan via iommu
2022-02-04 15:19 ` Zi Yan
2022-02-04 15:19 ` Zi Yan
2022-01-19 19:06 ` [PATCH v4 5/7] mm: cma: use pageblock_order as the single alignment Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` [PATCH v4 6/7] drivers: virtio_mem: use pageblock size as the minimum virtio_mem size Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` [PATCH v4 7/7] arch: powerpc: adjust fadump alignment to be pageblock aligned Zi Yan
2022-01-19 19:06 ` Zi Yan
2022-01-19 19:06 ` Zi Yan
-- strict thread matches above, loose matches on Subject: below --
2022-01-22 8:32 [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages kernel test robot
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=Yfp2rv0K6d3cNmwg@localhost.localdomain \
--to=osalvador@suse.de \
--cc=david@redhat.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@techsingularity.net \
--cc=mpe@ellerman.id.au \
--cc=renzhengeek@gmail.com \
--cc=robin.murphy@arm.com \
--cc=vbabka@suse.cz \
--cc=virtualization@lists.linux-foundation.org \
--cc=ziy@nvidia.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.