[PATCH] mm/zswap: export zswap API to modules

[PATCH] mm/zswap: export zswap API to modules

[Vitaly Wool]

There is no reason to not let modules use zswap capabilies to
densely store unused pages in RAM. This will allow to remove some
homebrew solutions for e.g. GPU drivers in favor of plainly using
zswap pool.

Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.se>
Signed-off-by: Igor Belousov <igor.b@beldev.am>
---
 mm/zswap.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/zswap.c b/mm/zswap.c
index 3c0fd8a13718..718d341f7482 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -502,6 +502,7 @@ unsigned long zswap_total_pages(void)
 
 	return total;
 }
+EXPORT_SYMBOL(zswap_total_pages);
 
 static bool zswap_check_limits(void)
 {
@@ -756,6 +757,7 @@ void zswap_folio_swapin(struct folio *folio)
 		atomic_long_inc(&lruvec->zswap_lruvec_state.nr_disk_swapins);
 	}
 }
+EXPORT_SYMBOL(zswap_folio_swapin);
 
 /*
  * This function should be called when a memcg is being offlined.
@@ -1638,6 +1640,7 @@ bool zswap_store(struct folio *folio)
 
 	return ret;
 }
+EXPORT_SYMBOL(zswap_store);
 
 /**
  * zswap_load() - load a folio from zswap
@@ -1718,6 +1721,7 @@ int zswap_load(struct folio *folio)
 	folio_unlock(folio);
 	return 0;
 }
+EXPORT_SYMBOL(zswap_load);
 
 void zswap_invalidate(swp_entry_t swp)
 {
@@ -1752,6 +1756,7 @@ int zswap_swapon(int type, unsigned long nr_pages)
 	zswap_trees[type] = trees;
 	return 0;
 }
+EXPORT_SYMBOL(zswap_swapon);
 
 void zswap_swapoff(int type)
 {
@@ -1769,6 +1774,7 @@ void zswap_swapoff(int type)
 	nr_zswap_trees[type] = 0;
 	zswap_trees[type] = NULL;
 }
+EXPORT_SYMBOL(zswap_swapoff);
 
 /*********************************
 * debugfs functions
-- 
2.39.2

Re: [PATCH] mm/zswap: export zswap API to modules

[Matthew Wilcox]

On Fri, Jun 20, 2025 at 09:35:52PM +0200, Vitaly Wool wrote:
> There is no reason to not let modules use zswap capabilies to
> densely store unused pages in RAM. This will allow to remove some
> homebrew solutions for e.g. GPU drivers in favor of plainly using
> zswap pool.

I really think these should be _GPL exports.  And I'm not sure why the
GPU drivers are using "homebrew solutions" instead of using the shmem
APIs which work whether zswap is configured in or not.

Re: [PATCH] mm/zswap: export zswap API to modules

[Christoph Hellwig]

On Fri, Jun 20, 2025 at 09:35:52PM +0200, Vitaly Wool wrote:
> There is no reason to not let modules use zswap capabilies to
> densely store unused pages in RAM. This will allow to remove some
> homebrew solutions for e.g. GPU drivers in favor of plainly using
> zswap pool.

Well, right now there very much is - there is no user of them.  And any
such user should first have a careful review on the list if they really
should use zswap directly because that feels like a layering violation.
(Maybe it's not, but without a proper review that is impossible to say)

And this was the nice Monday morning after a long weekend reply.  The
short form is "don't add exports without a user", and everyone should
really know that.

Re: [PATCH] mm/zswap: export zswap API to modules

[Vitaly Wool]

On 6/20/25 21:47, Matthew Wilcox wrote:
> On Fri, Jun 20, 2025 at 09:35:52PM +0200, Vitaly Wool wrote:
>> There is no reason to not let modules use zswap capabilies to
>> densely store unused pages in RAM. This will allow to remove some
>> homebrew solutions for e.g. GPU drivers in favor of plainly using
>> zswap pool.
> 
> I really think these should be _GPL exports.  And I'm not sure why the
> GPU drivers are using "homebrew solutions" instead of using the shmem
> APIs which work whether zswap is configured in or not.

shmem API adds an extra copy which would be nice to avoid. Changing 
exports to _GPL I have indeed no problem with.

~Vitaly

Re: [PATCH] mm/zswap: export zswap API to modules

[David Hildenbrand]

On 20.06.25 21:47, Matthew Wilcox wrote:
> On Fri, Jun 20, 2025 at 09:35:52PM +0200, Vitaly Wool wrote:
>> There is no reason to not let modules use zswap capabilies to
>> densely store unused pages in RAM. This will allow to remove some
>> homebrew solutions for e.g. GPU drivers in favor of plainly using
>> zswap pool.
> 
> I really think these should be _GPL exports.  And I'm not sure why the
> GPU drivers are using "homebrew solutions" instead of using the shmem
> APIs which work whether zswap is configured in or not.

In particular, because zswap is tightly glued to actual swap code (e.g., 
swap_writeout()), and we should review first if any such GPU user should 
really be talking to zswap directly.

-- 
Cheers,

David / dhildenb