[RFC] TTM shrinking revisited

[RFC] TTM shrinking revisited

[Thomas Hellström]

Hi, Christian, others.

I'm starting to take a look at the TTM shrinker again. We'll probably be
needing it at least for supporting integrated hardware with the xe driver.

So assuming that the last attempt failed because of the need to allocate
shmem pages and lack of writeback at shrink time, I was thinking of the
following approach: (A rough design sketch of the core support for the
last bullet is in patch 1/1. It of course needs polishing if the interface
is at all accepted by the mm people).

Before embarking on this, any feedback or comments would be greatly
appreciated:

*) Avoid TTM swapping when no swap space is available. Better to adjust the
   TTM swapout watermark, as no pages can be freed to the system anyway.
*) Complement the TTM swapout watermark with a shrinker.
   For cached pages, that may hopefully remove the need for the watermark.
   Possibly a watermark needs to remain for wc pages and / or dma pages,
   depending on how well shrinking them works.
*) Trigger immediate writeback of pages handed to the swapcache / shmem,
   at least when the shrinker is called from kswapd.
*) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the pool code
   we have more details about the backing pages and can split pages,
   transition caching state and copy as necessary. Also investigate the
   possibility of reusing pool pages in a smart way if copying is needed.
*) See if we can directly insert pages into the swap-cache instead of
   taking the shmem detour, something along with the attached patch 1 RFC.

Thanks,
Thomas

[RFC PATCH 1/1] mm: Add interfaces to back up and recover folio contents using swap

[Thomas Hellström]

GPU drivers have traditionally used shmem to back up GPU buffer contents
for swap on physical memory shortage. Some integrated GPU drivers use
shmem files as the backing storage for their GPU buffers, other drivers,
in particular drivers that need a Write-Combining caching strategy on
system pages, (but also drivers for discrete gpus in general) need to copy
to shmem on anticipated memory shortage.

The latter strategy does not lend itself very well to shrinker usage,
since in the shrinker, shmem memory up to PMD size first has to be
allocated before the gpu buffer page can be transitioned to normal caching
and handed back to the system.
This memory allocation will dive into kernel reserves allocating shmem
pages which aren't freed until a writeback happens from kswapd, which
makes the approach very fragile at best. Possibly one could transition
caching and split huge pages to be backed up before copying to shmem as an
alternative strategy.

Another approach is outlined in this RFC.

Add interfaces for GPU drivers to directly insert pages into the
swap-cache, thereby bypassing shmem and avoiding the shmem page
allocation at shrink time completely, as well as the content copy.

Also add a kunit test for experimenting with the interface functionality,
currently it seems PMD size folios doesn't work properly. Needs
further investigation if this is a viable approach. Also cgroup
accounting needs a thorough revisit.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 mm/Makefile                 |   3 +-
 mm/swap_backup_folio.c      | 134 ++++++++++++++++++++++++++++++++++++
 mm/swap_backup_folio_test.c | 109 +++++++++++++++++++++++++++++
 3 files changed, 245 insertions(+), 1 deletion(-)
 create mode 100644 mm/swap_backup_folio.c
 create mode 100644 mm/swap_backup_folio_test.c

diff --git a/mm/Makefile b/mm/Makefile
index 8e105e5b3e29..c7432d607f7a 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -54,7 +54,7 @@ obj-y			:= filemap.o mempool.o oom_kill.o fadvise.o \
 			   mm_init.o percpu.o slab_common.o \
 			   compaction.o \
 			   interval_tree.o list_lru.o workingset.o \
-			   debug.o gup.o mmap_lock.o $(mmu-y)
+			   debug.o gup.o mmap_lock.o swap_backup_folio.o $(mmu-y)
 
 # Give 'page_alloc' its own module-parameter namespace
 page-alloc-y := page_alloc.o
@@ -138,3 +138,4 @@ obj-$(CONFIG_IO_MAPPING) += io-mapping.o
 obj-$(CONFIG_HAVE_BOOTMEM_INFO_NODE) += bootmem_info.o
 obj-$(CONFIG_GENERIC_IOREMAP) += ioremap.o
 obj-$(CONFIG_SHRINKER_DEBUG) += shrinker_debug.o
+obj-m += swap_backup_folio_test.o
diff --git a/mm/swap_backup_folio.c b/mm/swap_backup_folio.c
new file mode 100644
index 000000000000..76b761a19f99
--- /dev/null
+++ b/mm/swap_backup_folio.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/mm_types.h>
+#include <linux/module.h>
+#include <linux/pagemap.h>
+#include <linux/swap.h>
+
+#include "swap.h"
+
+/**
+ * swap_backup_folio() - Insert an unmapped and dirty folio into the swap-cache.
+ * @folio: The folio to insert.
+ * @wbc: The struct writeback_control for immediate writeback or NULL.
+ *
+ * Insert a folio into the swap cache and get a swp_entry_t back as a reference.
+ * If the swap cache folio should be subject of immediate writeback to
+ * a swap device, @wbc should be non-NULL and point to a struct writeback_control
+ * populated accordingly. After a call to swap_backup_folio() the caller can
+ * drop its folio reference and use swap_recover_folio() to get the folio
+ * content back. Currently only PAGE_SIZE folios work, or if CONFIG_THP_SWAP is
+ * enabled, HPAGE_PMD_NR*PAGE_SIZE may work as well.
+ * TODO: Add a gfp_t to control the needed add_to_swap_cache radix tree
+ * allocation?
+ *
+ * Return: A swp_entry_t. If its .val field is zero, an error occurred.
+ */
+swp_entry_t swap_backup_folio(struct folio *folio,
+			      struct writeback_control *wbc)
+{
+	swp_entry_t swap = {};
+
+	if (folio_nr_pages(folio) != 1 &&
+	    !(IS_ENABLED(CONFIG_THP_SWAP) &&
+	      folio_nr_pages(folio) == HPAGE_PMD_NR))
+		return swap;
+
+	folio_lock(folio);
+	__folio_mark_uptodate(folio);
+	__folio_set_swapbacked(folio);
+
+	swap = folio_alloc_swap(folio);
+	if (!swap.val) {
+		folio_unlock(folio);
+		return swap;
+	}
+
+	mem_cgroup_charge(folio, NULL, GFP_HIGHUSER_MOVABLE);
+
+	if (add_to_swap_cache(folio, swap, __GFP_HIGH | __GFP_NOWARN, NULL) == 0) {
+		int ret = -EINVAL;
+
+		/*
+		 * Add a swapcount to prevent immediate swap-space reclaim of
+		 * this entry. It's paired with a swap_free() in
+		 * swap_recover_folio().
+		 */
+		swap_shmem_alloc(swap);
+		folio_add_lru(folio);
+
+		/*
+		 * Stolen from pageout(). The folio_test_writeback() looks a
+		 * bit arbitrary, as writepage unlocks the folio and the
+		 * writeback may complete at any time...
+		 */
+		if (wbc && folio_clear_dirty_for_io(folio)) {
+			folio_set_reclaim(folio);
+			ret = swap_writepage(folio_page(folio, 0), wbc);
+			if (!folio_test_writeback(folio))
+				folio_clear_reclaim(folio);
+		}
+
+		if (ret)
+			folio_unlock(folio);
+		return swap;
+	}
+
+	put_swap_folio(folio, swap);
+	folio_clear_swapbacked(folio);
+	folio_mark_dirty(folio);
+	folio_unlock(folio);
+
+	return swap;
+}
+EXPORT_SYMBOL(swap_backup_folio);
+
+/**
+ * swap_recover_folio() - Recover folio content that was previously backed up
+ * @swap: The swp_entry_t returned from swap_backup_folio().
+ *
+ * Recovers content that was previously backed up using swap_backup_folio().
+ * TODO: If a new folio is allocated, explain how the allocation policy is
+ * chosen. We may want to add that as an argument to the function
+ * together with a suitable gfp_t.
+ *
+ * Return: Pointer to folio containing the backed up content. This may or may
+ * not be the same folio used in the call to swap_backup_folio().
+ */
+struct folio *swap_recover_folio(swp_entry_t swap)
+{
+	struct folio *folio = swap_cache_get_folio(swap, NULL, 0);
+
+	if (!folio) {
+		/*
+		 * TODO: Use a fake vma (like shmem) for the desired
+		 * allocation policy?
+		 */
+		struct vm_fault vmf = {};
+		struct page *page;
+
+		/*
+		 * FIXME: Does this really work with PMD size folios, or
+		 * do we need to retry from start after readahead?
+		 */
+		page = swap_cluster_readahead(swap, GFP_HIGHUSER_MOVABLE, &vmf);
+		if (page)
+			folio = page_folio(page);
+	}
+
+	if (!folio)
+		return ERR_PTR(-ENOMEM);
+
+	folio_lock(folio);
+	WARN_ON(!folio_test_swapcache(folio) ||
+		folio_swap_entry(folio).val != swap.val ||
+		!folio_test_uptodate(folio));
+	folio_wait_writeback(folio);
+	arch_swap_restore(swap, folio);
+	delete_from_swap_cache(folio);
+	folio_unlock(folio);
+	swap_free(swap);
+
+	return folio;
+}
+EXPORT_SYMBOL(swap_recover_folio);
diff --git a/mm/swap_backup_folio_test.c b/mm/swap_backup_folio_test.c
new file mode 100644
index 000000000000..1d6a9447d78a
--- /dev/null
+++ b/mm/swap_backup_folio_test.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: MIT or GPL-2.0
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include <kunit/test.h>
+#include <linux/delay.h>
+#include <linux/swap.h>
+
+/* TODO: Use memory- and swap size info to determine this. */
+#define MAX_BACKUP_FOLIOS 5000000
+
+swp_entry_t swap_backup_folio(struct folio *folio, struct writeback_control *wbc);
+struct folio *swap_recover_folio(swp_entry_t swap);
+
+static struct writeback_control __maybe_unused wbc = {
+	.sync_mode = WB_SYNC_NONE,
+	.nr_to_write = SWAP_CLUSTER_MAX,
+	.range_start = 0,
+	.range_end = LLONG_MAX,
+	.for_reclaim = 1,
+};
+
+struct gpu_swapped_page {
+	struct list_head link;
+	swp_entry_t swap;
+};
+
+static void swap_backup_test(struct kunit *test)
+{
+	gfp_t gfp = GFP_HIGHUSER_MOVABLE | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
+	struct gpu_swapped_page *gsp, *next;
+	struct folio *folio;
+	LIST_HEAD(list);
+	int i = 0;
+
+	do {
+		/*
+		 * Expect folio_alloc() (out-of-physical-memory) or
+		 * swap_backup_folio() (out-of-swap-space) to fail before
+		 * this kzalloc().
+		 */
+		gsp = kzalloc(sizeof(*gsp), GFP_KERNEL);
+		if (!gsp) {
+			KUNIT_FAIL(test, "alloc gsp failed.\n");
+			break;
+		}
+
+		folio = vma_alloc_folio(gfp, 0, NULL, 0, false);
+		if (!folio) {
+			kunit_info(test, "folio_alloc failed.\n");
+			kfree(gsp);
+			break;
+		}
+
+		folio_mark_dirty(folio);
+
+		/* Use &wbc instead of NULL here to trigger immediate writeback. */
+		gsp->swap = swap_backup_folio(folio, NULL);
+		if (gsp->swap.val == 0) {
+			kunit_info(test, "swap_backup_folio() failed.\n");
+			folio_put(folio);
+			kfree(gsp);
+			break;
+		}
+
+		list_add_tail(&gsp->link, &list);
+		folio_put(folio);
+		if (i % 1000 == 0)
+			kunit_info(test, "Backed up %d\n", i);
+	} while (i++ < MAX_BACKUP_FOLIOS);
+
+	kunit_info(test, "Backup total: %d. Now sleeping for 10s.\n", i);
+	ssleep(10);
+
+	i = 0;
+	list_for_each_entry_safe(gsp, next, &list, link) {
+		folio = swap_recover_folio(gsp->swap);
+		if (IS_ERR(folio)) {
+			KUNIT_FAIL(test, "swap_recover_folio() failed.\n");
+		} else {
+			folio->memcg_data = 0;
+			folio_put(folio);
+		}
+		list_del(&gsp->link);
+		kfree(gsp);
+		i++;
+
+		if (i % 1000 == 0)
+			kunit_info(test, "Recovered %d\n", i);
+	}
+
+	kunit_info(test, "Recover_total: %d\n", i);
+}
+
+static struct kunit_case swap_backup_tests[] = {
+	KUNIT_CASE(swap_backup_test),
+	{}
+};
+
+static struct kunit_suite swap_backup_test_suite = {
+	.name = "swap_backup_folio",
+	.test_cases = swap_backup_tests,
+};
+
+kunit_test_suite(swap_backup_test_suite);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.38.1

Re: [RFC] TTM shrinking revisited

[Christian König]

Am 30.12.22 um 12:11 schrieb Thomas Hellström:
> Hi, Christian, others.
>
> I'm starting to take a look at the TTM shrinker again. We'll probably be
> needing it at least for supporting integrated hardware with the xe driver.
>
> So assuming that the last attempt failed because of the need to allocate
> shmem pages and lack of writeback at shrink time, I was thinking of the
> following approach: (A rough design sketch of the core support for the
> last bullet is in patch 1/1. It of course needs polishing if the interface
> is at all accepted by the mm people).
>
> Before embarking on this, any feedback or comments would be greatly
> appreciated:
>
> *) Avoid TTM swapping when no swap space is available. Better to adjust the
>     TTM swapout watermark, as no pages can be freed to the system anyway.
> *) Complement the TTM swapout watermark with a shrinker.
>     For cached pages, that may hopefully remove the need for the watermark.
>     Possibly a watermark needs to remain for wc pages and / or dma pages,
>     depending on how well shrinking them works.

Yeah, that's what I've already tried and failed miserable exactly 
because of what you described above.

> *) Trigger immediate writeback of pages handed to the swapcache / shmem,
>     at least when the shrinker is called from kswapd.

Not sure if that's really valuable.

> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the pool code
>     we have more details about the backing pages and can split pages,
>     transition caching state and copy as necessary. Also investigate the
>     possibility of reusing pool pages in a smart way if copying is needed.

Well I think we don't need to split pages at all. The higher order pages 
are just allocated for better TLB utilization and could (in theory) be 
freed as individual pages as well. It's just that MM doesn't support 
that atm.

But I really like the idea of moving more of this logic into the ttm_pool.

> *) See if we can directly insert pages into the swap-cache instead of
>     taking the shmem detour, something along with the attached patch 1 RFC.

Yeah, that strongly looks like we way to go. Maybe in combination with 
being able to swap WC/UC pages directly out.

While swapping them in again an extra copy doesn't hurt us, but for the 
other way that really sucks.

Thanks,
Christian.

>
> Thanks,
> Thomas
>

Re: [RFC] TTM shrinking revisited

[Thomas Hellström]

Hi, Christian,

Thanks for the feedback. Some additional inline comments and questions:

On 1/4/23 11:31, Christian König wrote:
> Am 30.12.22 um 12:11 schrieb Thomas Hellström:
>> Hi, Christian, others.
>>
>> I'm starting to take a look at the TTM shrinker again. We'll probably be
>> needing it at least for supporting integrated hardware with the xe 
>> driver.
>>
>> So assuming that the last attempt failed because of the need to allocate
>> shmem pages and lack of writeback at shrink time, I was thinking of the
>> following approach: (A rough design sketch of the core support for the
>> last bullet is in patch 1/1. It of course needs polishing if the 
>> interface
>> is at all accepted by the mm people).
>>
>> Before embarking on this, any feedback or comments would be greatly
>> appreciated:
>>
>> *) Avoid TTM swapping when no swap space is available. Better to 
>> adjust the
>>     TTM swapout watermark, as no pages can be freed to the system 
>> anyway.
>> *) Complement the TTM swapout watermark with a shrinker.
>>     For cached pages, that may hopefully remove the need for the 
>> watermark.
>>     Possibly a watermark needs to remain for wc pages and / or dma 
>> pages,
>>     depending on how well shrinking them works.
>
> Yeah, that's what I've already tried and failed miserable exactly 
> because of what you described above.

Do you have a test-case for this or a typical failing scenario I can 
turn into a kunit test, to motivate the need for direct 
insert-to-swap-cache before running it with the -mm people? It will 
otherwise have a high risk of being NAKed, I fear.

>
>> *) Trigger immediate writeback of pages handed to the swapcache / shmem,
>>     at least when the shrinker is called from kswapd.
>
> Not sure if that's really valuable.
Not completely sure either. However, in OOM situations where we need to 
allocate memory to be able to shrink, that would give the system a 
chance to reclaim the pages we shrink before we deplete the kernel 
reserves completely. Shmem does this, and also the i915 shrinker in some 
situations, but I agree it needs to be verified to be valuable and if 
so, in what situations.

>
>> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the pool 
>> code
>>     we have more details about the backing pages and can split pages,
>>     transition caching state and copy as necessary. Also investigate the
>>     possibility of reusing pool pages in a smart way if copying is 
>> needed.
>
> Well I think we don't need to split pages at all. The higher order 
> pages are just allocated for better TLB utilization and could (in 
> theory) be freed as individual pages as well. It's just that MM 
> doesn't support that atm.

If we can insert pages directly into the swap-cache, splitting might be 
needed, at least if compound pages were allocated to begin with. Looks 
like shmem does this as well before inserting into the swap-cache. Could 
be a corner case where the system theoretically supports swapping PMD 
size pages, but when no PMD size slots are available. (My system behaves 
like that, need to investigate why).


Thanks,

Thomas


>
> But I really like the idea of moving more of this logic into the 
> ttm_pool.
>
>> *) See if we can directly insert pages into the swap-cache instead of
>>     taking the shmem detour, something along with the attached patch 
>> 1 RFC.
>
> Yeah, that strongly looks like we way to go. Maybe in combination with 
> being able to swap WC/UC pages directly out.
>
> While swapping them in again an extra copy doesn't hurt us, but for 
> the other way that really sucks.
>
> Thanks,
> Christian.
>
>>
>> Thanks,
>> Thomas
>>
>

Re: [RFC] TTM shrinking revisited

[Christian König]

Am 09.01.23 um 10:14 schrieb Thomas Hellström:
> Hi, Christian,
>
> Thanks for the feedback. Some additional inline comments and questions:
>
> On 1/4/23 11:31, Christian König wrote:
>> Am 30.12.22 um 12:11 schrieb Thomas Hellström:
>>> Hi, Christian, others.
>>>
>>> I'm starting to take a look at the TTM shrinker again. We'll 
>>> probably be
>>> needing it at least for supporting integrated hardware with the xe 
>>> driver.
>>>
>>> So assuming that the last attempt failed because of the need to 
>>> allocate
>>> shmem pages and lack of writeback at shrink time, I was thinking of the
>>> following approach: (A rough design sketch of the core support for the
>>> last bullet is in patch 1/1. It of course needs polishing if the 
>>> interface
>>> is at all accepted by the mm people).
>>>
>>> Before embarking on this, any feedback or comments would be greatly
>>> appreciated:
>>>
>>> *) Avoid TTM swapping when no swap space is available. Better to 
>>> adjust the
>>>     TTM swapout watermark, as no pages can be freed to the system 
>>> anyway.
>>> *) Complement the TTM swapout watermark with a shrinker.
>>>     For cached pages, that may hopefully remove the need for the 
>>> watermark.
>>>     Possibly a watermark needs to remain for wc pages and / or dma 
>>> pages,
>>>     depending on how well shrinking them works.
>>
>> Yeah, that's what I've already tried and failed miserable exactly 
>> because of what you described above.
>
> Do you have a test-case for this or a typical failing scenario I can 
> turn into a kunit test, to motivate the need for direct 
> insert-to-swap-cache before running it with the -mm people? It will 
> otherwise have a high risk of being NAKed, I fear.

No real test case, but Piglit has a test where an application tries to 
allocate texture which gets bigger and bigger until we run into an ENOMEM.

Without the 50% limit we crash pretty easily in an OOM situation.

>
>>
>>> *) Trigger immediate writeback of pages handed to the swapcache / 
>>> shmem,
>>>     at least when the shrinker is called from kswapd.
>>
>> Not sure if that's really valuable.
> Not completely sure either. However, in OOM situations where we need 
> to allocate memory to be able to shrink, that would give the system a 
> chance to reclaim the pages we shrink before we deplete the kernel 
> reserves completely. Shmem does this, and also the i915 shrinker in 
> some situations, but I agree it needs to be verified to be valuable 
> and if so, in what situations.
>
>>
>>> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the 
>>> pool code
>>>     we have more details about the backing pages and can split pages,
>>>     transition caching state and copy as necessary. Also investigate 
>>> the
>>>     possibility of reusing pool pages in a smart way if copying is 
>>> needed.
>>
>> Well I think we don't need to split pages at all. The higher order 
>> pages are just allocated for better TLB utilization and could (in 
>> theory) be freed as individual pages as well. It's just that MM 
>> doesn't support that atm.
>
> If we can insert pages directly into the swap-cache, splitting might 
> be needed, at least if compound pages were allocated to begin with. 
> Looks like shmem does this as well before inserting into the 
> swap-cache. Could be a corner case where the system theoretically 
> supports swapping PMD size pages, but when no PMD size slots are 
> available. (My system behaves like that, need to investigate why).

Mhm, sounds like my understanding of the swap-cache is completely 
outdated. Not much of a surprise, it was more than a decade ago that I 
last looked into this.

Christian.

>
>
>
> Thanks,
>
> Thomas
>
>
>>
>> But I really like the idea of moving more of this logic into the 
>> ttm_pool.
>>
>>> *) See if we can directly insert pages into the swap-cache instead of
>>>     taking the shmem detour, something along with the attached patch 
>>> 1 RFC.
>>
>> Yeah, that strongly looks like we way to go. Maybe in combination 
>> with being able to swap WC/UC pages directly out.
>>
>> While swapping them in again an extra copy doesn't hurt us, but for 
>> the other way that really sucks.
>>
>> Thanks,
>> Christian.
>>
>>>
>>> Thanks,
>>> Thomas
>>>
>>

Re: [RFC] TTM shrinking revisited

[Thomas Hellström]

On 1/4/23 11:31, Christian König wrote:
> Am 30.12.22 um 12:11 schrieb Thomas Hellström:
>> Hi, Christian, others.
>>
>> I'm starting to take a look at the TTM shrinker again. We'll probably be
>> needing it at least for supporting integrated hardware with the xe 
>> driver.
>>
>> So assuming that the last attempt failed because of the need to allocate
>> shmem pages and lack of writeback at shrink time, I was thinking of the
>> following approach: (A rough design sketch of the core support for the
>> last bullet is in patch 1/1. It of course needs polishing if the 
>> interface
>> is at all accepted by the mm people).
>>
>> Before embarking on this, any feedback or comments would be greatly
>> appreciated:
>>
>> *) Avoid TTM swapping when no swap space is available. Better to 
>> adjust the
>>     TTM swapout watermark, as no pages can be freed to the system 
>> anyway.
>> *) Complement the TTM swapout watermark with a shrinker.
>>     For cached pages, that may hopefully remove the need for the 
>> watermark.
>>     Possibly a watermark needs to remain for wc pages and / or dma 
>> pages,
>>     depending on how well shrinking them works.
>
> Yeah, that's what I've already tried and failed miserable exactly 
> because of what you described above.
>
>> *) Trigger immediate writeback of pages handed to the swapcache / shmem,
>>     at least when the shrinker is called from kswapd.
>
> Not sure if that's really valuable.
>
>> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the pool 
>> code
>>     we have more details about the backing pages and can split pages,
>>     transition caching state and copy as necessary. Also investigate the
>>     possibility of reusing pool pages in a smart way if copying is 
>> needed.
>
> Well I think we don't need to split pages at all. The higher order 
> pages are just allocated for better TLB utilization and could (in 
> theory) be freed as individual pages as well. It's just that MM 
> doesn't support that atm.
>
> But I really like the idea of moving more of this logic into the 
> ttm_pool.
>
>> *) See if we can directly insert pages into the swap-cache instead of
>>     taking the shmem detour, something along with the attached patch 
>> 1 RFC.
>
> Yeah, that strongly looks like we way to go. Maybe in combination with 
> being able to swap WC/UC pages directly out.
>
Christian, I was wondering here if

1) There is something stopping us from using __GFP_COMP and folios? 
Reason is that for, for example a 2MiB page, if we can't insert it 
directly for whatever reason, we don't want to allocate 2MiB worth of 
swap memory before actually handing any memory back, and so may need to 
call split_folio().

2) Also any objections to restricting the page allocation sizes to 
PMD_SIZE and SZ_4K, again for split_folio().

Thanks,

Thomas


> While swapping them in again an extra copy doesn't hurt us, but for 
> the other way that really sucks.
>
> Thanks,
> Christian.
>
>>
>> Thanks,
>> Thomas
>>
>

Re: [RFC] TTM shrinking revisited

[Christian König]

Hi Thomas,

Am 23.01.23 um 15:59 schrieb Thomas Hellström:
>
> On 1/4/23 11:31, Christian König wrote:
>> Am 30.12.22 um 12:11 schrieb Thomas Hellström:
>>> Hi, Christian, others.
>>>
>>> I'm starting to take a look at the TTM shrinker again. We'll 
>>> probably be
>>> needing it at least for supporting integrated hardware with the xe 
>>> driver.
>>>
>>> So assuming that the last attempt failed because of the need to 
>>> allocate
>>> shmem pages and lack of writeback at shrink time, I was thinking of the
>>> following approach: (A rough design sketch of the core support for the
>>> last bullet is in patch 1/1. It of course needs polishing if the 
>>> interface
>>> is at all accepted by the mm people).
>>>
>>> Before embarking on this, any feedback or comments would be greatly
>>> appreciated:
>>>
>>> *) Avoid TTM swapping when no swap space is available. Better to 
>>> adjust the
>>>     TTM swapout watermark, as no pages can be freed to the system 
>>> anyway.
>>> *) Complement the TTM swapout watermark with a shrinker.
>>>     For cached pages, that may hopefully remove the need for the 
>>> watermark.
>>>     Possibly a watermark needs to remain for wc pages and / or dma 
>>> pages,
>>>     depending on how well shrinking them works.
>>
>> Yeah, that's what I've already tried and failed miserable exactly 
>> because of what you described above.
>>
>>> *) Trigger immediate writeback of pages handed to the swapcache / 
>>> shmem,
>>>     at least when the shrinker is called from kswapd.
>>
>> Not sure if that's really valuable.
>>
>>> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the 
>>> pool code
>>>     we have more details about the backing pages and can split pages,
>>>     transition caching state and copy as necessary. Also investigate 
>>> the
>>>     possibility of reusing pool pages in a smart way if copying is 
>>> needed.
>>
>> Well I think we don't need to split pages at all. The higher order 
>> pages are just allocated for better TLB utilization and could (in 
>> theory) be freed as individual pages as well. It's just that MM 
>> doesn't support that atm.
>>
>> But I really like the idea of moving more of this logic into the 
>> ttm_pool.
>>
>>> *) See if we can directly insert pages into the swap-cache instead of
>>>     taking the shmem detour, something along with the attached patch 
>>> 1 RFC.
>>
>> Yeah, that strongly looks like we way to go. Maybe in combination 
>> with being able to swap WC/UC pages directly out.
>>
> Christian, I was wondering here if
>
> 1) There is something stopping us from using __GFP_COMP and folios? 
> Reason is that for, for example a 2MiB page, if we can't insert it 
> directly for whatever reason, we don't want to allocate 2MiB worth of 
> swap memory before actually handing any memory back, and so may need 
> to call split_folio().

I've tried __GFP_COMP before and ran into massive problems. Folios 
didn't existed at that point, so they are probably worth a try now.

>
> 2) Also any objections to restricting the page allocation sizes to 
> PMD_SIZE and SZ_4K, again for split_folio().

We can't do that. A lot of applications assuming 64K as huge page size 
for GPUs cause that used to be the standard under Windows.

So only supporting 4K and 2M would result in quite some performance drop 
for those.

Christian.

>
> Thanks,
>
> Thomas
>
>
>> While swapping them in again an extra copy doesn't hurt us, but for 
>> the other way that really sucks.
>>
>> Thanks,
>> Christian.
>>
>>>
>>> Thanks,
>>> Thomas
>>>
>>

Re: [RFC] TTM shrinking revisited

[Thomas Hellström]

Hi, Christian,

On 1/23/23 17:07, Christian König wrote:
> Hi Thomas,
>
> Am 23.01.23 um 15:59 schrieb Thomas Hellström:
>>
>> On 1/4/23 11:31, Christian König wrote:
>>> Am 30.12.22 um 12:11 schrieb Thomas Hellström:
>>>> Hi, Christian, others.
>>>>
>>>> I'm starting to take a look at the TTM shrinker again. We'll 
>>>> probably be
>>>> needing it at least for supporting integrated hardware with the xe 
>>>> driver.
>>>>
>>>> So assuming that the last attempt failed because of the need to 
>>>> allocate
>>>> shmem pages and lack of writeback at shrink time, I was thinking of 
>>>> the
>>>> following approach: (A rough design sketch of the core support for the
>>>> last bullet is in patch 1/1. It of course needs polishing if the 
>>>> interface
>>>> is at all accepted by the mm people).
>>>>
>>>> Before embarking on this, any feedback or comments would be greatly
>>>> appreciated:
>>>>
>>>> *) Avoid TTM swapping when no swap space is available. Better to 
>>>> adjust the
>>>>     TTM swapout watermark, as no pages can be freed to the system 
>>>> anyway.
>>>> *) Complement the TTM swapout watermark with a shrinker.
>>>>     For cached pages, that may hopefully remove the need for the 
>>>> watermark.
>>>>     Possibly a watermark needs to remain for wc pages and / or dma 
>>>> pages,
>>>>     depending on how well shrinking them works.
>>>
>>> Yeah, that's what I've already tried and failed miserable exactly 
>>> because of what you described above.
>>>
>>>> *) Trigger immediate writeback of pages handed to the swapcache / 
>>>> shmem,
>>>>     at least when the shrinker is called from kswapd.
>>>
>>> Not sure if that's really valuable.
>>>
>>>> *) Hide ttm_tt_swap[out|in] details in the ttm_pool code. In the 
>>>> pool code
>>>>     we have more details about the backing pages and can split pages,
>>>>     transition caching state and copy as necessary. Also 
>>>> investigate the
>>>>     possibility of reusing pool pages in a smart way if copying is 
>>>> needed.
>>>
>>> Well I think we don't need to split pages at all. The higher order 
>>> pages are just allocated for better TLB utilization and could (in 
>>> theory) be freed as individual pages as well. It's just that MM 
>>> doesn't support that atm.
>>>
>>> But I really like the idea of moving more of this logic into the 
>>> ttm_pool.
>>>
>>>> *) See if we can directly insert pages into the swap-cache instead of
>>>>     taking the shmem detour, something along with the attached 
>>>> patch 1 RFC.
>>>
>>> Yeah, that strongly looks like we way to go. Maybe in combination 
>>> with being able to swap WC/UC pages directly out.
>>>
>> Christian, I was wondering here if
>>
>> 1) There is something stopping us from using __GFP_COMP and folios? 
>> Reason is that for, for example a 2MiB page, if we can't insert it 
>> directly for whatever reason, we don't want to allocate 2MiB worth of 
>> swap memory before actually handing any memory back, and so may need 
>> to call split_folio().
>
> I've tried __GFP_COMP before and ran into massive problems. Folios 
> didn't existed at that point, so they are probably worth a try now.

OK, I'll give it a try. A quick try on i915 with TTM __GFP_COMP system 
pages seems to work well.

>
>>
>> 2) Also any objections to restricting the page allocation sizes to 
>> PMD_SIZE and SZ_4K, again for split_folio().
>
> We can't do that. A lot of applications assuming 64K as huge page size 
> for GPUs cause that used to be the standard under Windows.
>
> So only supporting 4K and 2M would result in quite some performance 
> drop for those.

OK, understood.

/Thomas


>
> Christian.
>
>>
>> Thanks,
>>
>> Thomas
>>
>>
>>> While swapping them in again an extra copy doesn't hurt us, but for 
>>> the other way that really sucks.
>>>
>>> Thanks,
>>> Christian.
>>>
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>
>