2019-05-19 12:08:20 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2016-05-20 23:58:30 +00:00
|
|
|
/*
|
|
|
|
* z3fold.c
|
|
|
|
*
|
|
|
|
* Author: Vitaly Wool <vitaly.wool@konsulko.com>
|
|
|
|
* Copyright (C) 2016, Sony Mobile Communications Inc.
|
|
|
|
*
|
|
|
|
* This implementation is based on zbud written by Seth Jennings.
|
|
|
|
*
|
|
|
|
* z3fold is an special purpose allocator for storing compressed pages. It
|
|
|
|
* can store up to three compressed pages per page which improves the
|
|
|
|
* compression ratio of zbud while retaining its main concepts (e. g. always
|
|
|
|
* storing an integral number of objects per page) and simplicity.
|
|
|
|
* It still has simple and deterministic reclaim properties that make it
|
|
|
|
* preferable to a higher density approach (with no requirement on integral
|
|
|
|
* number of object per page) when reclaim is used.
|
|
|
|
*
|
|
|
|
* As in zbud, pages are divided into "chunks". The size of the chunks is
|
|
|
|
* fixed at compile time and is determined by NCHUNKS_ORDER below.
|
|
|
|
*
|
|
|
|
* z3fold doesn't export any API and is meant to be used via zpool API.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
|
|
|
#include <linux/atomic.h>
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
#include <linux/sched.h>
|
2019-05-14 00:22:52 +00:00
|
|
|
#include <linux/cpumask.h>
|
2016-05-20 23:58:30 +00:00
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/module.h>
|
2019-05-14 00:22:52 +00:00
|
|
|
#include <linux/page-flags.h>
|
|
|
|
#include <linux/migrate.h>
|
|
|
|
#include <linux/node.h>
|
|
|
|
#include <linux/compaction.h>
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
#include <linux/percpu.h>
|
2016-05-20 23:58:30 +00:00
|
|
|
#include <linux/preempt.h>
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
#include <linux/workqueue.h>
|
2016-05-20 23:58:30 +00:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/zpool.h>
|
2020-05-28 05:20:40 +00:00
|
|
|
#include <linux/kmemleak.h>
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2019-05-14 00:22:49 +00:00
|
|
|
/*
|
|
|
|
* NCHUNKS_ORDER determines the internal allocation granularity, effectively
|
|
|
|
* adjusting internal fragmentation. It also determines the number of
|
|
|
|
* freelists maintained in each pool. NCHUNKS_ORDER of 6 means that the
|
|
|
|
* allocation granularity will be in chunks of size PAGE_SIZE/64. Some chunks
|
|
|
|
* in the beginning of an allocated page are occupied by z3fold header, so
|
|
|
|
* NCHUNKS will be calculated to 63 (or 62 in case CONFIG_DEBUG_SPINLOCK=y),
|
|
|
|
* which shows the max number of free chunks in z3fold page, also there will
|
|
|
|
* be 63, or 62, respectively, freelists per pool.
|
|
|
|
*/
|
|
|
|
#define NCHUNKS_ORDER 6
|
|
|
|
|
|
|
|
#define CHUNK_SHIFT (PAGE_SHIFT - NCHUNKS_ORDER)
|
|
|
|
#define CHUNK_SIZE (1 << CHUNK_SHIFT)
|
|
|
|
#define ZHDR_SIZE_ALIGNED round_up(sizeof(struct z3fold_header), CHUNK_SIZE)
|
|
|
|
#define ZHDR_CHUNKS (ZHDR_SIZE_ALIGNED >> CHUNK_SHIFT)
|
|
|
|
#define TOTAL_CHUNKS (PAGE_SIZE >> CHUNK_SHIFT)
|
2021-07-01 01:50:24 +00:00
|
|
|
#define NCHUNKS (TOTAL_CHUNKS - ZHDR_CHUNKS)
|
2019-05-14 00:22:49 +00:00
|
|
|
|
|
|
|
#define BUDDY_MASK (0x3)
|
|
|
|
#define BUDDY_SHIFT 2
|
|
|
|
#define SLOTS_ALIGN (0x40)
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/*****************
|
|
|
|
* Structures
|
|
|
|
*****************/
|
2017-02-24 22:57:17 +00:00
|
|
|
struct z3fold_pool;
|
|
|
|
|
|
|
|
enum buddy {
|
|
|
|
HEADLESS = 0,
|
|
|
|
FIRST,
|
|
|
|
MIDDLE,
|
|
|
|
LAST,
|
2019-05-14 00:22:49 +00:00
|
|
|
BUDDIES_MAX = LAST
|
|
|
|
};
|
|
|
|
|
|
|
|
struct z3fold_buddy_slots {
|
|
|
|
/*
|
|
|
|
* we are using BUDDY_MASK in handle_to_buddy etc. so there should
|
|
|
|
* be enough slots to hold all possible variants
|
|
|
|
*/
|
|
|
|
unsigned long slot[BUDDY_MASK + 1];
|
2020-12-15 03:12:30 +00:00
|
|
|
unsigned long pool; /* back link */
|
2019-12-01 01:56:11 +00:00
|
|
|
rwlock_t lock;
|
2017-02-24 22:57:17 +00:00
|
|
|
};
|
2019-05-14 00:22:49 +00:00
|
|
|
#define HANDLE_FLAG_MASK (0x03)
|
2017-02-24 22:57:17 +00:00
|
|
|
|
|
|
|
/*
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* struct z3fold_header - z3fold page metadata occupying first chunks of each
|
2017-02-24 22:57:17 +00:00
|
|
|
* z3fold page, except for HEADLESS pages
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @buddy: links the z3fold page into the relevant list in the
|
|
|
|
* pool
|
2017-02-24 22:57:23 +00:00
|
|
|
* @page_lock: per-page lock
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @refcount: reference count for the z3fold page
|
|
|
|
* @work: work_struct for page layout optimization
|
2019-05-14 00:22:49 +00:00
|
|
|
* @slots: pointer to the structure holding buddy slots
|
2019-07-16 23:25:48 +00:00
|
|
|
* @pool: pointer to the containing pool
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @cpu: CPU which this page "belongs" to
|
2017-02-24 22:57:17 +00:00
|
|
|
* @first_chunks: the size of the first buddy in chunks, 0 if free
|
|
|
|
* @middle_chunks: the size of the middle buddy in chunks, 0 if free
|
|
|
|
* @last_chunks: the size of the last buddy in chunks, 0 if free
|
|
|
|
* @first_num: the starting number (for the first handle)
|
2019-05-14 00:22:52 +00:00
|
|
|
* @mapped_count: the number of objects currently mapped
|
2017-02-24 22:57:17 +00:00
|
|
|
*/
|
|
|
|
struct z3fold_header {
|
|
|
|
struct list_head buddy;
|
2017-02-24 22:57:23 +00:00
|
|
|
spinlock_t page_lock;
|
2017-02-24 22:57:26 +00:00
|
|
|
struct kref refcount;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
struct work_struct work;
|
2019-05-14 00:22:49 +00:00
|
|
|
struct z3fold_buddy_slots *slots;
|
2019-07-16 23:25:48 +00:00
|
|
|
struct z3fold_pool *pool;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
short cpu;
|
2017-02-24 22:57:17 +00:00
|
|
|
unsigned short first_chunks;
|
|
|
|
unsigned short middle_chunks;
|
|
|
|
unsigned short last_chunks;
|
|
|
|
unsigned short start_middle;
|
|
|
|
unsigned short first_num:2;
|
2019-05-14 00:22:52 +00:00
|
|
|
unsigned short mapped_count:2;
|
2019-12-01 01:56:11 +00:00
|
|
|
unsigned short foreign_handles:2;
|
2017-02-24 22:57:17 +00:00
|
|
|
};
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/**
|
|
|
|
* struct z3fold_pool - stores metadata for each z3fold pool
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @name: pool name
|
2023-06-12 09:38:11 +00:00
|
|
|
* @lock: protects pool unbuddied lists
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @stale_lock: protects pool stale page list
|
|
|
|
* @unbuddied: per-cpu array of lists tracking z3fold pages that contain 2-
|
|
|
|
* buddies; the list each z3fold page is added to depends on
|
|
|
|
* the size of its free region.
|
|
|
|
* @stale: list of pages marked for freeing
|
2016-05-20 23:58:30 +00:00
|
|
|
* @pages_nr: number of z3fold pages in the pool.
|
2019-05-14 00:22:49 +00:00
|
|
|
* @c_handle: cache for z3fold_buddy_slots allocation
|
2021-07-01 01:53:44 +00:00
|
|
|
* @zpool: zpool driver
|
|
|
|
* @zpool_ops: zpool operations structure with an evict callback
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
* @compact_wq: workqueue for page layout background optimization
|
|
|
|
* @release_wq: workqueue for safe page release
|
|
|
|
* @work: work_struct for safe page release
|
2016-05-20 23:58:30 +00:00
|
|
|
*
|
|
|
|
* This structure is allocated at pool creation time and maintains metadata
|
|
|
|
* pertaining to a particular z3fold pool.
|
|
|
|
*/
|
|
|
|
struct z3fold_pool {
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
const char *name;
|
2016-05-20 23:58:30 +00:00
|
|
|
spinlock_t lock;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
spinlock_t stale_lock;
|
|
|
|
struct list_head *unbuddied;
|
|
|
|
struct list_head stale;
|
2017-02-24 22:57:15 +00:00
|
|
|
atomic64_t pages_nr;
|
2019-05-14 00:22:49 +00:00
|
|
|
struct kmem_cache *c_handle;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
struct workqueue_struct *compact_wq;
|
|
|
|
struct workqueue_struct *release_wq;
|
|
|
|
struct work_struct work;
|
2016-05-20 23:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal z3fold page flags
|
|
|
|
*/
|
|
|
|
enum z3fold_page_flags {
|
2017-02-24 22:57:26 +00:00
|
|
|
PAGE_HEADLESS = 0,
|
2016-05-20 23:58:30 +00:00
|
|
|
MIDDLE_CHUNK_MAPPED,
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
NEEDS_COMPACTING,
|
2018-05-11 23:01:46 +00:00
|
|
|
PAGE_STALE,
|
2018-11-16 23:07:56 +00:00
|
|
|
PAGE_CLAIMED, /* by either reclaim or free */
|
2022-04-29 06:40:43 +00:00
|
|
|
PAGE_MIGRATED, /* page is migrated and soon to be released */
|
2016-05-20 23:58:30 +00:00
|
|
|
};
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
/*
|
|
|
|
* handle flags, go under HANDLE_FLAG_MASK
|
|
|
|
*/
|
|
|
|
enum z3fold_handle_flags {
|
|
|
|
HANDLES_NOFREE = 0,
|
|
|
|
};
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
/*
|
|
|
|
* Forward declarations
|
|
|
|
*/
|
|
|
|
static struct z3fold_header *__z3fold_alloc(struct z3fold_pool *, size_t, bool);
|
|
|
|
static void compact_page_work(struct work_struct *w);
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/*****************
|
|
|
|
* Helpers
|
|
|
|
*****************/
|
|
|
|
|
|
|
|
/* Converts an allocation size in bytes to size in z3fold chunks */
|
|
|
|
static int size_to_chunks(size_t size)
|
|
|
|
{
|
|
|
|
return (size + CHUNK_SIZE - 1) >> CHUNK_SHIFT;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define for_each_unbuddied_list(_iter, _begin) \
|
|
|
|
for ((_iter) = (_begin); (_iter) < NCHUNKS; (_iter)++)
|
|
|
|
|
2019-06-01 05:30:39 +00:00
|
|
|
static inline struct z3fold_buddy_slots *alloc_slots(struct z3fold_pool *pool,
|
|
|
|
gfp_t gfp)
|
2019-05-14 00:22:49 +00:00
|
|
|
{
|
2022-04-29 06:40:43 +00:00
|
|
|
struct z3fold_buddy_slots *slots = kmem_cache_zalloc(pool->c_handle,
|
|
|
|
gfp);
|
2019-05-14 00:22:49 +00:00
|
|
|
|
|
|
|
if (slots) {
|
2020-05-28 05:20:40 +00:00
|
|
|
/* It will be freed separately in free_handle(). */
|
|
|
|
kmemleak_not_leak(slots);
|
2019-05-14 00:22:49 +00:00
|
|
|
slots->pool = (unsigned long)pool;
|
2019-12-01 01:56:11 +00:00
|
|
|
rwlock_init(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return slots;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct z3fold_pool *slots_to_pool(struct z3fold_buddy_slots *s)
|
|
|
|
{
|
|
|
|
return (struct z3fold_pool *)(s->pool & ~HANDLE_FLAG_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct z3fold_buddy_slots *handle_to_slots(unsigned long handle)
|
|
|
|
{
|
|
|
|
return (struct z3fold_buddy_slots *)(handle & ~(SLOTS_ALIGN - 1));
|
|
|
|
}
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
/* Lock a z3fold page */
|
|
|
|
static inline void z3fold_page_lock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
spin_lock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Try to lock a z3fold page */
|
|
|
|
static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
return spin_trylock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Unlock a z3fold page */
|
|
|
|
static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
spin_unlock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
2021-07-01 01:50:33 +00:00
|
|
|
/* return locked z3fold page if it's not headless */
|
|
|
|
static inline struct z3fold_header *get_z3fold_header(unsigned long handle)
|
2019-12-01 01:56:11 +00:00
|
|
|
{
|
|
|
|
struct z3fold_buddy_slots *slots;
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
int locked = 0;
|
|
|
|
|
|
|
|
if (!(handle & (1 << PAGE_HEADLESS))) {
|
|
|
|
slots = handle_to_slots(handle);
|
|
|
|
do {
|
|
|
|
unsigned long addr;
|
|
|
|
|
|
|
|
read_lock(&slots->lock);
|
|
|
|
addr = *(unsigned long *)handle;
|
|
|
|
zhdr = (struct z3fold_header *)(addr & PAGE_MASK);
|
2021-07-01 01:50:33 +00:00
|
|
|
locked = z3fold_page_trylock(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
read_unlock(&slots->lock);
|
2022-04-29 06:40:43 +00:00
|
|
|
if (locked) {
|
|
|
|
struct page *page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
if (!test_bit(PAGE_MIGRATED, &page->private))
|
|
|
|
break;
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
2019-12-01 01:56:11 +00:00
|
|
|
cpu_relax();
|
2021-07-01 01:50:33 +00:00
|
|
|
} while (true);
|
2019-12-01 01:56:11 +00:00
|
|
|
} else {
|
|
|
|
zhdr = (struct z3fold_header *)(handle & PAGE_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
return zhdr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void put_z3fold_header(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
struct page *page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
if (!test_bit(PAGE_HEADLESS, &page->private))
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
|
|
|
|
2020-12-15 03:12:30 +00:00
|
|
|
static inline void free_handle(unsigned long handle, struct z3fold_header *zhdr)
|
2019-05-14 00:22:49 +00:00
|
|
|
{
|
|
|
|
struct z3fold_buddy_slots *slots;
|
|
|
|
int i;
|
|
|
|
bool is_free;
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
if (WARN_ON(*(unsigned long *)handle == 0))
|
|
|
|
return;
|
|
|
|
|
2019-05-14 00:22:49 +00:00
|
|
|
slots = handle_to_slots(handle);
|
2019-12-01 01:56:11 +00:00
|
|
|
write_lock(&slots->lock);
|
|
|
|
*(unsigned long *)handle = 0;
|
2020-12-15 03:12:33 +00:00
|
|
|
|
|
|
|
if (test_bit(HANDLES_NOFREE, &slots->pool)) {
|
|
|
|
write_unlock(&slots->lock);
|
|
|
|
return; /* simple case, nothing else to do */
|
|
|
|
}
|
|
|
|
|
2020-12-15 03:12:30 +00:00
|
|
|
if (zhdr->slots != slots)
|
|
|
|
zhdr->foreign_handles--;
|
2019-12-01 01:56:11 +00:00
|
|
|
|
2019-05-14 00:22:49 +00:00
|
|
|
is_free = true;
|
|
|
|
for (i = 0; i <= BUDDY_MASK; i++) {
|
|
|
|
if (slots->slot[i]) {
|
|
|
|
is_free = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2020-05-23 05:23:12 +00:00
|
|
|
write_unlock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
|
|
|
|
if (is_free) {
|
|
|
|
struct z3fold_pool *pool = slots_to_pool(slots);
|
|
|
|
|
2020-12-15 03:12:30 +00:00
|
|
|
if (zhdr->slots == slots)
|
|
|
|
zhdr->slots = NULL;
|
2019-05-14 00:22:49 +00:00
|
|
|
kmem_cache_free(pool->c_handle, slots);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/* Initializes the z3fold header of a newly allocated z3fold page */
|
2019-09-23 22:36:51 +00:00
|
|
|
static struct z3fold_header *init_z3fold_page(struct page *page, bool headless,
|
2019-06-01 05:30:39 +00:00
|
|
|
struct z3fold_pool *pool, gfp_t gfp)
|
2016-05-20 23:58:30 +00:00
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = page_address(page);
|
2019-09-23 22:36:51 +00:00
|
|
|
struct z3fold_buddy_slots *slots;
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
clear_bit(PAGE_HEADLESS, &page->private);
|
|
|
|
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
clear_bit(NEEDS_COMPACTING, &page->private);
|
|
|
|
clear_bit(PAGE_STALE, &page->private);
|
2018-11-16 23:07:56 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2022-04-29 06:40:43 +00:00
|
|
|
clear_bit(PAGE_MIGRATED, &page->private);
|
2019-09-23 22:36:51 +00:00
|
|
|
if (headless)
|
|
|
|
return zhdr;
|
|
|
|
|
|
|
|
slots = alloc_slots(pool, gfp);
|
|
|
|
if (!slots)
|
|
|
|
return NULL;
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2021-02-24 20:09:22 +00:00
|
|
|
memset(zhdr, 0, sizeof(*zhdr));
|
2017-02-24 22:57:23 +00:00
|
|
|
spin_lock_init(&zhdr->page_lock);
|
2017-02-24 22:57:26 +00:00
|
|
|
kref_init(&zhdr->refcount);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
zhdr->cpu = -1;
|
2019-05-14 00:22:49 +00:00
|
|
|
zhdr->slots = slots;
|
2019-07-16 23:25:48 +00:00
|
|
|
zhdr->pool = pool;
|
2016-05-20 23:58:30 +00:00
|
|
|
INIT_LIST_HEAD(&zhdr->buddy);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
INIT_WORK(&zhdr->work, compact_page_work);
|
2016-05-20 23:58:30 +00:00
|
|
|
return zhdr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Resets the struct page fields and frees the page */
|
2019-05-14 00:22:52 +00:00
|
|
|
static void free_z3fold_page(struct page *page, bool headless)
|
2016-05-20 23:58:30 +00:00
|
|
|
{
|
2019-05-14 00:22:52 +00:00
|
|
|
if (!headless) {
|
|
|
|
lock_page(page);
|
|
|
|
__ClearPageMovable(page);
|
|
|
|
unlock_page(page);
|
|
|
|
}
|
2017-02-24 22:57:26 +00:00
|
|
|
__free_page(page);
|
|
|
|
}
|
|
|
|
|
2019-05-14 00:22:49 +00:00
|
|
|
/* Helper function to build the index */
|
|
|
|
static inline int __idx(struct z3fold_header *zhdr, enum buddy bud)
|
|
|
|
{
|
|
|
|
return (bud + zhdr->first_num) & BUDDY_MASK;
|
|
|
|
}
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/*
|
|
|
|
* Encodes the handle of a particular buddy within a z3fold page
|
|
|
|
* Pool lock should be held as this function accesses first_num
|
|
|
|
*/
|
2019-09-23 22:33:02 +00:00
|
|
|
static unsigned long __encode_handle(struct z3fold_header *zhdr,
|
|
|
|
struct z3fold_buddy_slots *slots,
|
|
|
|
enum buddy bud)
|
2016-05-20 23:58:30 +00:00
|
|
|
{
|
2019-05-14 00:22:49 +00:00
|
|
|
unsigned long h = (unsigned long)zhdr;
|
|
|
|
int idx = 0;
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2019-05-14 00:22:49 +00:00
|
|
|
/*
|
|
|
|
* For a headless page, its handle is its pointer with the extra
|
|
|
|
* PAGE_HEADLESS bit set
|
|
|
|
*/
|
|
|
|
if (bud == HEADLESS)
|
|
|
|
return h | (1 << PAGE_HEADLESS);
|
|
|
|
|
|
|
|
/* otherwise, return pointer to encoded handle */
|
|
|
|
idx = __idx(zhdr, bud);
|
|
|
|
h += idx;
|
|
|
|
if (bud == LAST)
|
|
|
|
h |= (zhdr->last_chunks << BUDDY_SHIFT);
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
write_lock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
slots->slot[idx] = h;
|
2019-12-01 01:56:11 +00:00
|
|
|
write_unlock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
return (unsigned long)&slots->slot[idx];
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
2019-09-23 22:33:02 +00:00
|
|
|
static unsigned long encode_handle(struct z3fold_header *zhdr, enum buddy bud)
|
|
|
|
{
|
|
|
|
return __encode_handle(zhdr, zhdr->slots, bud);
|
|
|
|
}
|
|
|
|
|
2018-11-16 23:07:56 +00:00
|
|
|
/* only for LAST bud, returns zero otherwise */
|
|
|
|
static unsigned short handle_to_chunks(unsigned long handle)
|
|
|
|
{
|
2019-12-01 01:56:11 +00:00
|
|
|
struct z3fold_buddy_slots *slots = handle_to_slots(handle);
|
|
|
|
unsigned long addr;
|
2019-05-14 00:22:49 +00:00
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
read_lock(&slots->lock);
|
|
|
|
addr = *(unsigned long *)handle;
|
|
|
|
read_unlock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
return (addr & ~PAGE_MASK) >> BUDDY_SHIFT;
|
2018-11-16 23:07:56 +00:00
|
|
|
}
|
|
|
|
|
2017-02-22 23:46:51 +00:00
|
|
|
/*
|
|
|
|
* (handle & BUDDY_MASK) < zhdr->first_num is possible in encode_handle
|
|
|
|
* but that doesn't matter. because the masking will result in the
|
|
|
|
* correct buddy number.
|
|
|
|
*/
|
2016-05-20 23:58:30 +00:00
|
|
|
static enum buddy handle_to_buddy(unsigned long handle)
|
|
|
|
{
|
2019-05-14 00:22:49 +00:00
|
|
|
struct z3fold_header *zhdr;
|
2019-12-01 01:56:11 +00:00
|
|
|
struct z3fold_buddy_slots *slots = handle_to_slots(handle);
|
2019-05-14 00:22:49 +00:00
|
|
|
unsigned long addr;
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
read_lock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
WARN_ON(handle & (1 << PAGE_HEADLESS));
|
|
|
|
addr = *(unsigned long *)handle;
|
2019-12-01 01:56:11 +00:00
|
|
|
read_unlock(&slots->lock);
|
2019-05-14 00:22:49 +00:00
|
|
|
zhdr = (struct z3fold_header *)(addr & PAGE_MASK);
|
|
|
|
return (addr - zhdr->first_num) & BUDDY_MASK;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
static inline struct z3fold_pool *zhdr_to_pool(struct z3fold_header *zhdr)
|
|
|
|
{
|
2019-07-16 23:25:48 +00:00
|
|
|
return zhdr->pool;
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
}
|
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
static void __release_z3fold_page(struct z3fold_header *zhdr, bool locked)
|
|
|
|
{
|
|
|
|
struct page *page = virt_to_page(zhdr);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
struct z3fold_pool *pool = zhdr_to_pool(zhdr);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
|
|
|
|
WARN_ON(!list_empty(&zhdr->buddy));
|
|
|
|
set_bit(PAGE_STALE, &page->private);
|
2017-10-03 23:15:06 +00:00
|
|
|
clear_bit(NEEDS_COMPACTING, &page->private);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
spin_lock(&pool->lock);
|
|
|
|
spin_unlock(&pool->lock);
|
2019-12-01 01:56:11 +00:00
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
if (locked)
|
|
|
|
z3fold_page_unlock(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
list_add(&zhdr->buddy, &pool->stale);
|
|
|
|
queue_work(pool->release_wq, &pool->work);
|
|
|
|
spin_unlock(&pool->stale_lock);
|
2022-04-29 06:16:05 +00:00
|
|
|
|
|
|
|
atomic64_dec(&pool->pages_nr);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void release_z3fold_page_locked(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
|
|
|
|
refcount);
|
|
|
|
WARN_ON(z3fold_page_trylock(zhdr));
|
|
|
|
__release_z3fold_page(zhdr, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void release_z3fold_page_locked_list(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
|
|
|
|
refcount);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
struct z3fold_pool *pool = zhdr_to_pool(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
spin_lock(&pool->lock);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
list_del_init(&zhdr->buddy);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
spin_unlock(&pool->lock);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
|
|
|
|
WARN_ON(z3fold_page_trylock(zhdr));
|
|
|
|
__release_z3fold_page(zhdr, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_pages_work(struct work_struct *w)
|
|
|
|
{
|
|
|
|
struct z3fold_pool *pool = container_of(w, struct z3fold_pool, work);
|
|
|
|
|
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
while (!list_empty(&pool->stale)) {
|
|
|
|
struct z3fold_header *zhdr = list_first_entry(&pool->stale,
|
|
|
|
struct z3fold_header, buddy);
|
|
|
|
struct page *page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
list_del(&zhdr->buddy);
|
|
|
|
if (WARN_ON(!test_bit(PAGE_STALE, &page->private)))
|
|
|
|
continue;
|
|
|
|
spin_unlock(&pool->stale_lock);
|
|
|
|
cancel_work_sync(&zhdr->work);
|
2019-05-14 00:22:52 +00:00
|
|
|
free_z3fold_page(page, false);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
cond_resched();
|
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
}
|
|
|
|
spin_unlock(&pool->stale_lock);
|
|
|
|
}
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/*
|
|
|
|
* Returns the number of free chunks in a z3fold page.
|
|
|
|
* NB: can't be used with HEADLESS pages.
|
|
|
|
*/
|
|
|
|
static int num_free_chunks(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
int nfree;
|
|
|
|
/*
|
|
|
|
* If there is a middle object, pick up the bigger free space
|
|
|
|
* either before or after it. Otherwise just subtract the number
|
|
|
|
* of chunks occupied by the first and the last objects.
|
|
|
|
*/
|
|
|
|
if (zhdr->middle_chunks != 0) {
|
|
|
|
int nfree_before = zhdr->first_chunks ?
|
2017-02-24 22:57:17 +00:00
|
|
|
0 : zhdr->start_middle - ZHDR_CHUNKS;
|
2016-05-20 23:58:30 +00:00
|
|
|
int nfree_after = zhdr->last_chunks ?
|
2017-02-24 22:57:17 +00:00
|
|
|
0 : TOTAL_CHUNKS -
|
|
|
|
(zhdr->start_middle + zhdr->middle_chunks);
|
2016-05-20 23:58:30 +00:00
|
|
|
nfree = max(nfree_before, nfree_after);
|
|
|
|
} else
|
|
|
|
nfree = NCHUNKS - zhdr->first_chunks - zhdr->last_chunks;
|
|
|
|
return nfree;
|
|
|
|
}
|
|
|
|
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
/* Add to the appropriate unbuddied list */
|
|
|
|
static inline void add_to_unbuddied(struct z3fold_pool *pool,
|
|
|
|
struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0 ||
|
|
|
|
zhdr->middle_chunks == 0) {
|
2020-12-15 03:12:36 +00:00
|
|
|
struct list_head *unbuddied;
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
int freechunks = num_free_chunks(zhdr);
|
2020-12-15 03:12:36 +00:00
|
|
|
|
|
|
|
migrate_disable();
|
|
|
|
unbuddied = this_cpu_ptr(pool->unbuddied);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&zhdr->buddy, &unbuddied[freechunks]);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
zhdr->cpu = smp_processor_id();
|
2020-12-15 03:12:36 +00:00
|
|
|
migrate_enable();
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
static inline enum buddy get_free_buddy(struct z3fold_header *zhdr, int chunks)
|
|
|
|
{
|
|
|
|
enum buddy bud = HEADLESS;
|
|
|
|
|
|
|
|
if (zhdr->middle_chunks) {
|
|
|
|
if (!zhdr->first_chunks &&
|
|
|
|
chunks <= zhdr->start_middle - ZHDR_CHUNKS)
|
|
|
|
bud = FIRST;
|
|
|
|
else if (!zhdr->last_chunks)
|
|
|
|
bud = LAST;
|
|
|
|
} else {
|
|
|
|
if (!zhdr->first_chunks)
|
|
|
|
bud = FIRST;
|
|
|
|
else if (!zhdr->last_chunks)
|
|
|
|
bud = LAST;
|
|
|
|
else
|
|
|
|
bud = MIDDLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return bud;
|
|
|
|
}
|
|
|
|
|
2017-02-24 22:57:17 +00:00
|
|
|
static inline void *mchunk_memmove(struct z3fold_header *zhdr,
|
|
|
|
unsigned short dst_chunk)
|
|
|
|
{
|
|
|
|
void *beg = zhdr;
|
|
|
|
return memmove(beg + (dst_chunk << CHUNK_SHIFT),
|
|
|
|
beg + (zhdr->start_middle << CHUNK_SHIFT),
|
|
|
|
zhdr->middle_chunks << CHUNK_SHIFT);
|
|
|
|
}
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
static inline bool buddy_single(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
return !((zhdr->first_chunks && zhdr->middle_chunks) ||
|
|
|
|
(zhdr->first_chunks && zhdr->last_chunks) ||
|
|
|
|
(zhdr->middle_chunks && zhdr->last_chunks));
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct z3fold_header *compact_single_buddy(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
struct z3fold_pool *pool = zhdr_to_pool(zhdr);
|
|
|
|
void *p = zhdr;
|
|
|
|
unsigned long old_handle = 0;
|
|
|
|
size_t sz = 0;
|
|
|
|
struct z3fold_header *new_zhdr = NULL;
|
|
|
|
int first_idx = __idx(zhdr, FIRST);
|
|
|
|
int middle_idx = __idx(zhdr, MIDDLE);
|
|
|
|
int last_idx = __idx(zhdr, LAST);
|
|
|
|
unsigned short *moved_chunks = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No need to protect slots here -- all the slots are "local" and
|
|
|
|
* the page lock is already taken
|
|
|
|
*/
|
|
|
|
if (zhdr->first_chunks && zhdr->slots->slot[first_idx]) {
|
|
|
|
p += ZHDR_SIZE_ALIGNED;
|
|
|
|
sz = zhdr->first_chunks << CHUNK_SHIFT;
|
|
|
|
old_handle = (unsigned long)&zhdr->slots->slot[first_idx];
|
|
|
|
moved_chunks = &zhdr->first_chunks;
|
|
|
|
} else if (zhdr->middle_chunks && zhdr->slots->slot[middle_idx]) {
|
|
|
|
p += zhdr->start_middle << CHUNK_SHIFT;
|
|
|
|
sz = zhdr->middle_chunks << CHUNK_SHIFT;
|
|
|
|
old_handle = (unsigned long)&zhdr->slots->slot[middle_idx];
|
|
|
|
moved_chunks = &zhdr->middle_chunks;
|
|
|
|
} else if (zhdr->last_chunks && zhdr->slots->slot[last_idx]) {
|
|
|
|
p += PAGE_SIZE - (zhdr->last_chunks << CHUNK_SHIFT);
|
|
|
|
sz = zhdr->last_chunks << CHUNK_SHIFT;
|
|
|
|
old_handle = (unsigned long)&zhdr->slots->slot[last_idx];
|
|
|
|
moved_chunks = &zhdr->last_chunks;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sz > 0) {
|
|
|
|
enum buddy new_bud = HEADLESS;
|
|
|
|
short chunks = size_to_chunks(sz);
|
|
|
|
void *q;
|
|
|
|
|
|
|
|
new_zhdr = __z3fold_alloc(pool, sz, false);
|
|
|
|
if (!new_zhdr)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (WARN_ON(new_zhdr == zhdr))
|
|
|
|
goto out_fail;
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
new_bud = get_free_buddy(new_zhdr, chunks);
|
2019-12-01 01:56:11 +00:00
|
|
|
q = new_zhdr;
|
|
|
|
switch (new_bud) {
|
|
|
|
case FIRST:
|
|
|
|
new_zhdr->first_chunks = chunks;
|
|
|
|
q += ZHDR_SIZE_ALIGNED;
|
|
|
|
break;
|
|
|
|
case MIDDLE:
|
|
|
|
new_zhdr->middle_chunks = chunks;
|
|
|
|
new_zhdr->start_middle =
|
|
|
|
new_zhdr->first_chunks + ZHDR_CHUNKS;
|
|
|
|
q += new_zhdr->start_middle << CHUNK_SHIFT;
|
|
|
|
break;
|
|
|
|
case LAST:
|
|
|
|
new_zhdr->last_chunks = chunks;
|
|
|
|
q += PAGE_SIZE - (new_zhdr->last_chunks << CHUNK_SHIFT);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto out_fail;
|
|
|
|
}
|
|
|
|
new_zhdr->foreign_handles++;
|
|
|
|
memcpy(q, p, sz);
|
|
|
|
write_lock(&zhdr->slots->lock);
|
|
|
|
*(unsigned long *)old_handle = (unsigned long)new_zhdr +
|
|
|
|
__idx(new_zhdr, new_bud);
|
|
|
|
if (new_bud == LAST)
|
|
|
|
*(unsigned long *)old_handle |=
|
|
|
|
(new_zhdr->last_chunks << BUDDY_SHIFT);
|
|
|
|
write_unlock(&zhdr->slots->lock);
|
|
|
|
add_to_unbuddied(pool, new_zhdr);
|
|
|
|
z3fold_page_unlock(new_zhdr);
|
|
|
|
|
|
|
|
*moved_chunks = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return new_zhdr;
|
|
|
|
|
|
|
|
out_fail:
|
2022-04-29 06:16:05 +00:00
|
|
|
if (new_zhdr && !kref_put(&new_zhdr->refcount, release_z3fold_page_locked)) {
|
|
|
|
add_to_unbuddied(pool, new_zhdr);
|
|
|
|
z3fold_page_unlock(new_zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-02-24 22:57:20 +00:00
|
|
|
#define BIG_CHUNK_GAP 3
|
2016-05-20 23:58:30 +00:00
|
|
|
/* Has to be called with lock held */
|
|
|
|
static int z3fold_compact_page(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
struct page *page = virt_to_page(zhdr);
|
|
|
|
|
2017-02-24 22:57:17 +00:00
|
|
|
if (test_bit(MIDDLE_CHUNK_MAPPED, &page->private))
|
|
|
|
return 0; /* can't move middle chunk, it's used */
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2019-05-14 00:22:52 +00:00
|
|
|
if (unlikely(PageIsolated(page)))
|
|
|
|
return 0;
|
|
|
|
|
2017-02-24 22:57:17 +00:00
|
|
|
if (zhdr->middle_chunks == 0)
|
|
|
|
return 0; /* nothing to compact */
|
|
|
|
|
|
|
|
if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
|
|
|
|
/* move to the beginning */
|
|
|
|
mchunk_memmove(zhdr, ZHDR_CHUNKS);
|
2016-05-20 23:58:30 +00:00
|
|
|
zhdr->first_chunks = zhdr->middle_chunks;
|
|
|
|
zhdr->middle_chunks = 0;
|
|
|
|
zhdr->start_middle = 0;
|
|
|
|
zhdr->first_num++;
|
2017-02-24 22:57:20 +00:00
|
|
|
return 1;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
2017-02-24 22:57:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* moving data is expensive, so let's only do that if
|
|
|
|
* there's substantial gain (at least BIG_CHUNK_GAP chunks)
|
|
|
|
*/
|
|
|
|
if (zhdr->first_chunks != 0 && zhdr->last_chunks == 0 &&
|
|
|
|
zhdr->start_middle - (zhdr->first_chunks + ZHDR_CHUNKS) >=
|
|
|
|
BIG_CHUNK_GAP) {
|
|
|
|
mchunk_memmove(zhdr, zhdr->first_chunks + ZHDR_CHUNKS);
|
|
|
|
zhdr->start_middle = zhdr->first_chunks + ZHDR_CHUNKS;
|
|
|
|
return 1;
|
|
|
|
} else if (zhdr->last_chunks != 0 && zhdr->first_chunks == 0 &&
|
|
|
|
TOTAL_CHUNKS - (zhdr->last_chunks + zhdr->start_middle
|
|
|
|
+ zhdr->middle_chunks) >=
|
|
|
|
BIG_CHUNK_GAP) {
|
|
|
|
unsigned short new_start = TOTAL_CHUNKS - zhdr->last_chunks -
|
|
|
|
zhdr->middle_chunks;
|
|
|
|
mchunk_memmove(zhdr, new_start);
|
|
|
|
zhdr->start_middle = new_start;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
static void do_compact_page(struct z3fold_header *zhdr, bool locked)
|
|
|
|
{
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
struct z3fold_pool *pool = zhdr_to_pool(zhdr);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
struct page *page;
|
|
|
|
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
if (locked)
|
|
|
|
WARN_ON(z3fold_page_trylock(zhdr));
|
|
|
|
else
|
|
|
|
z3fold_page_lock(zhdr);
|
2017-11-17 23:26:16 +00:00
|
|
|
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
2022-04-29 06:16:05 +00:00
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked))
|
2017-11-17 23:26:16 +00:00
|
|
|
return;
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
if (test_bit(PAGE_STALE, &page->private) ||
|
|
|
|
test_and_set_bit(PAGE_CLAIMED, &page->private)) {
|
2019-05-14 00:22:52 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
if (!zhdr->foreign_handles && buddy_single(zhdr) &&
|
|
|
|
zhdr->mapped_count == 0 && compact_single_buddy(zhdr)) {
|
2022-04-29 06:16:05 +00:00
|
|
|
if (!kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
|
2020-12-15 03:12:33 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2019-12-01 01:56:11 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
2020-12-15 03:12:33 +00:00
|
|
|
}
|
2019-12-01 01:56:11 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
z3fold_compact_page(zhdr);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
add_to_unbuddied(pool, zhdr);
|
2020-12-15 03:12:33 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void compact_page_work(struct work_struct *w)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = container_of(w, struct z3fold_header,
|
|
|
|
work);
|
|
|
|
|
|
|
|
do_compact_page(zhdr, false);
|
|
|
|
}
|
|
|
|
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
/* returns _locked_ z3fold page header or NULL */
|
|
|
|
static inline struct z3fold_header *__z3fold_alloc(struct z3fold_pool *pool,
|
|
|
|
size_t size, bool can_sleep)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = NULL;
|
|
|
|
struct page *page;
|
|
|
|
struct list_head *unbuddied;
|
|
|
|
int chunks = size_to_chunks(size), i;
|
|
|
|
|
|
|
|
lookup:
|
2020-12-15 03:12:36 +00:00
|
|
|
migrate_disable();
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
/* First, try to find an unbuddied z3fold page. */
|
2020-12-15 03:12:36 +00:00
|
|
|
unbuddied = this_cpu_ptr(pool->unbuddied);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
for_each_unbuddied_list(i, chunks) {
|
|
|
|
struct list_head *l = &unbuddied[i];
|
|
|
|
|
|
|
|
zhdr = list_first_entry_or_null(READ_ONCE(l),
|
|
|
|
struct z3fold_header, buddy);
|
|
|
|
|
|
|
|
if (!zhdr)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Re-check under lock. */
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
if (unlikely(zhdr != list_first_entry(READ_ONCE(l),
|
|
|
|
struct z3fold_header, buddy)) ||
|
|
|
|
!z3fold_page_trylock(zhdr)) {
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
zhdr = NULL;
|
2020-12-15 03:12:36 +00:00
|
|
|
migrate_enable();
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
if (can_sleep)
|
|
|
|
cond_resched();
|
|
|
|
goto lookup;
|
|
|
|
}
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
zhdr->cpu = -1;
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
|
|
|
page = virt_to_page(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
if (test_bit(NEEDS_COMPACTING, &page->private) ||
|
|
|
|
test_bit(PAGE_CLAIMED, &page->private)) {
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
zhdr = NULL;
|
2020-12-15 03:12:36 +00:00
|
|
|
migrate_enable();
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
if (can_sleep)
|
|
|
|
cond_resched();
|
|
|
|
goto lookup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* this page could not be removed from its unbuddied
|
|
|
|
* list while pool lock was held, and then we've taken
|
|
|
|
* page lock so kref_put could not be called before
|
|
|
|
* we got here, so it's safe to just call kref_get()
|
|
|
|
*/
|
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
break;
|
|
|
|
}
|
2020-12-15 03:12:36 +00:00
|
|
|
migrate_enable();
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
|
2019-05-14 00:22:46 +00:00
|
|
|
if (!zhdr) {
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
/* look for _exact_ match on other cpus' lists */
|
|
|
|
for_each_online_cpu(cpu) {
|
|
|
|
struct list_head *l;
|
|
|
|
|
|
|
|
unbuddied = per_cpu_ptr(pool->unbuddied, cpu);
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
l = &unbuddied[chunks];
|
|
|
|
|
|
|
|
zhdr = list_first_entry_or_null(READ_ONCE(l),
|
|
|
|
struct z3fold_header, buddy);
|
|
|
|
|
|
|
|
if (!zhdr || !z3fold_page_trylock(zhdr)) {
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
zhdr = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
zhdr->cpu = -1;
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
|
|
|
page = virt_to_page(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
if (test_bit(NEEDS_COMPACTING, &page->private) ||
|
|
|
|
test_bit(PAGE_CLAIMED, &page->private)) {
|
2019-05-14 00:22:46 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
zhdr = NULL;
|
|
|
|
if (can_sleep)
|
|
|
|
cond_resched();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-04-29 06:40:43 +00:00
|
|
|
if (zhdr && !zhdr->slots) {
|
2022-04-29 06:40:43 +00:00
|
|
|
zhdr->slots = alloc_slots(pool, GFP_ATOMIC);
|
2022-04-29 06:40:43 +00:00
|
|
|
if (!zhdr->slots)
|
|
|
|
goto out_fail;
|
|
|
|
}
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
return zhdr;
|
2022-04-29 06:40:43 +00:00
|
|
|
|
|
|
|
out_fail:
|
|
|
|
if (!kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
|
|
|
|
add_to_unbuddied(pool, zhdr);
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
|
|
|
return NULL;
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
}
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* API Functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_create_pool() - create a new z3fold pool
|
|
|
|
* @name: pool name
|
|
|
|
* @gfp: gfp flags when allocating the z3fold pool structure
|
|
|
|
*
|
|
|
|
* Return: pointer to the new z3fold pool or NULL if the metadata allocation
|
|
|
|
* failed.
|
|
|
|
*/
|
2022-11-28 19:16:11 +00:00
|
|
|
static struct z3fold_pool *z3fold_create_pool(const char *name, gfp_t gfp)
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
{
|
|
|
|
struct z3fold_pool *pool = NULL;
|
|
|
|
int i, cpu;
|
|
|
|
|
|
|
|
pool = kzalloc(sizeof(struct z3fold_pool), gfp);
|
|
|
|
if (!pool)
|
|
|
|
goto out;
|
2019-05-14 00:22:49 +00:00
|
|
|
pool->c_handle = kmem_cache_create("z3fold_handle",
|
|
|
|
sizeof(struct z3fold_buddy_slots),
|
|
|
|
SLOTS_ALIGN, 0, NULL);
|
|
|
|
if (!pool->c_handle)
|
|
|
|
goto out_c;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
spin_lock_init(&pool->lock);
|
|
|
|
spin_lock_init(&pool->stale_lock);
|
2021-07-01 01:50:30 +00:00
|
|
|
pool->unbuddied = __alloc_percpu(sizeof(struct list_head) * NCHUNKS,
|
|
|
|
__alignof__(struct list_head));
|
2018-04-10 23:29:34 +00:00
|
|
|
if (!pool->unbuddied)
|
|
|
|
goto out_pool;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct list_head *unbuddied =
|
|
|
|
per_cpu_ptr(pool->unbuddied, cpu);
|
|
|
|
for_each_unbuddied_list(i, 0)
|
|
|
|
INIT_LIST_HEAD(&unbuddied[i]);
|
|
|
|
}
|
|
|
|
INIT_LIST_HEAD(&pool->stale);
|
|
|
|
atomic64_set(&pool->pages_nr, 0);
|
|
|
|
pool->name = name;
|
|
|
|
pool->compact_wq = create_singlethread_workqueue(pool->name);
|
|
|
|
if (!pool->compact_wq)
|
2018-04-10 23:29:34 +00:00
|
|
|
goto out_unbuddied;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
pool->release_wq = create_singlethread_workqueue(pool->name);
|
|
|
|
if (!pool->release_wq)
|
|
|
|
goto out_wq;
|
|
|
|
INIT_WORK(&pool->work, free_pages_work);
|
|
|
|
return pool;
|
|
|
|
|
|
|
|
out_wq:
|
|
|
|
destroy_workqueue(pool->compact_wq);
|
2018-04-10 23:29:34 +00:00
|
|
|
out_unbuddied:
|
|
|
|
free_percpu(pool->unbuddied);
|
|
|
|
out_pool:
|
2019-05-14 00:22:49 +00:00
|
|
|
kmem_cache_destroy(pool->c_handle);
|
|
|
|
out_c:
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
kfree(pool);
|
2018-04-10 23:29:34 +00:00
|
|
|
out:
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_destroy_pool() - destroys an existing z3fold pool
|
|
|
|
* @pool: the z3fold pool to be destroyed
|
|
|
|
*
|
|
|
|
* The pool should be emptied before this function is called.
|
|
|
|
*/
|
|
|
|
static void z3fold_destroy_pool(struct z3fold_pool *pool)
|
|
|
|
{
|
2019-05-14 00:22:49 +00:00
|
|
|
kmem_cache_destroy(pool->c_handle);
|
2019-08-13 22:37:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to destroy pool->compact_wq before pool->release_wq,
|
|
|
|
* as any pending work on pool->compact_wq will call
|
|
|
|
* queue_work(pool->release_wq, &pool->work).
|
2019-08-13 22:37:25 +00:00
|
|
|
*
|
|
|
|
* There are still outstanding pages until both workqueues are drained,
|
|
|
|
* so we cannot unregister migration until then.
|
2019-08-13 22:37:21 +00:00
|
|
|
*/
|
|
|
|
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
destroy_workqueue(pool->compact_wq);
|
2019-08-13 22:37:21 +00:00
|
|
|
destroy_workqueue(pool->release_wq);
|
2021-07-01 01:50:36 +00:00
|
|
|
free_percpu(pool->unbuddied);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
kfree(pool);
|
|
|
|
}
|
|
|
|
|
2022-06-07 19:38:48 +00:00
|
|
|
static const struct movable_operations z3fold_mops;
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/**
|
|
|
|
* z3fold_alloc() - allocates a region of a given size
|
|
|
|
* @pool: z3fold pool from which to allocate
|
|
|
|
* @size: size in bytes of the desired allocation
|
|
|
|
* @gfp: gfp flags used if the pool needs to grow
|
|
|
|
* @handle: handle of the new allocation
|
|
|
|
*
|
|
|
|
* This function will attempt to find a free region in the pool large enough to
|
|
|
|
* satisfy the allocation request. A search of the unbuddied lists is
|
|
|
|
* performed first. If no suitable free region is found, then a new page is
|
|
|
|
* allocated and added to the pool to satisfy the request.
|
|
|
|
*
|
|
|
|
* Return: 0 if success and handle is set, otherwise -EINVAL if the size or
|
|
|
|
* gfp arguments are invalid or -ENOMEM if the pool was unable to allocate
|
|
|
|
* a new page.
|
|
|
|
*/
|
|
|
|
static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp,
|
|
|
|
unsigned long *handle)
|
|
|
|
{
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
int chunks = size_to_chunks(size);
|
2016-05-20 23:58:30 +00:00
|
|
|
struct z3fold_header *zhdr = NULL;
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
struct page *page = NULL;
|
2016-05-20 23:58:30 +00:00
|
|
|
enum buddy bud;
|
2018-04-10 23:29:37 +00:00
|
|
|
bool can_sleep = gfpflags_allow_blocking(gfp);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2022-04-29 06:40:43 +00:00
|
|
|
if (!size || (gfp & __GFP_HIGHMEM))
|
2016-05-20 23:58:30 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (size > PAGE_SIZE)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE)
|
|
|
|
bud = HEADLESS;
|
|
|
|
else {
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
retry:
|
|
|
|
zhdr = __z3fold_alloc(pool, size, can_sleep);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
if (zhdr) {
|
2020-12-15 03:12:33 +00:00
|
|
|
bud = get_free_buddy(zhdr, chunks);
|
|
|
|
if (bud == HEADLESS) {
|
2022-04-29 06:16:05 +00:00
|
|
|
if (!kref_put(&zhdr->refcount,
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
release_z3fold_page_locked))
|
|
|
|
z3fold_page_unlock(zhdr);
|
2017-02-24 22:57:23 +00:00
|
|
|
pr_err("No free chunks in unbuddied\n");
|
|
|
|
WARN_ON(1);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
goto retry;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
page = virt_to_page(zhdr);
|
2017-02-24 22:57:23 +00:00
|
|
|
goto found;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
bud = FIRST;
|
|
|
|
}
|
|
|
|
|
2022-04-29 06:40:43 +00:00
|
|
|
page = alloc_page(gfp);
|
2016-05-20 23:58:30 +00:00
|
|
|
if (!page)
|
|
|
|
return -ENOMEM;
|
2017-02-24 22:57:23 +00:00
|
|
|
|
2019-09-23 22:36:51 +00:00
|
|
|
zhdr = init_z3fold_page(page, bud == HEADLESS, pool, gfp);
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
if (!zhdr) {
|
|
|
|
__free_page(page);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
atomic64_inc(&pool->pages_nr);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
if (bud == HEADLESS) {
|
|
|
|
set_bit(PAGE_HEADLESS, &page->private);
|
|
|
|
goto headless;
|
|
|
|
}
|
2019-07-12 03:52:14 +00:00
|
|
|
if (can_sleep) {
|
|
|
|
lock_page(page);
|
2022-06-07 19:38:48 +00:00
|
|
|
__SetPageMovable(page, &z3fold_mops);
|
2019-07-12 03:52:14 +00:00
|
|
|
unlock_page(page);
|
|
|
|
} else {
|
2022-04-29 06:40:43 +00:00
|
|
|
WARN_ON(!trylock_page(page));
|
2022-06-07 19:38:48 +00:00
|
|
|
__SetPageMovable(page, &z3fold_mops);
|
2022-04-29 06:40:43 +00:00
|
|
|
unlock_page(page);
|
2019-07-12 03:52:14 +00:00
|
|
|
}
|
2017-02-24 22:57:23 +00:00
|
|
|
z3fold_page_lock(zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
found:
|
|
|
|
if (bud == FIRST)
|
|
|
|
zhdr->first_chunks = chunks;
|
|
|
|
else if (bud == LAST)
|
|
|
|
zhdr->last_chunks = chunks;
|
|
|
|
else {
|
|
|
|
zhdr->middle_chunks = chunks;
|
2017-02-24 22:57:17 +00:00
|
|
|
zhdr->start_middle = zhdr->first_chunks + ZHDR_CHUNKS;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 00:22:43 +00:00
|
|
|
add_to_unbuddied(pool, zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
headless:
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
spin_lock(&pool->lock);
|
2016-05-20 23:58:30 +00:00
|
|
|
*handle = encode_handle(zhdr, bud);
|
|
|
|
spin_unlock(&pool->lock);
|
2017-02-24 22:57:23 +00:00
|
|
|
if (bud != HEADLESS)
|
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_free() - frees the allocation associated with the given handle
|
|
|
|
* @pool: pool in which the allocation resided
|
|
|
|
* @handle: handle associated with the allocation returned by z3fold_alloc()
|
|
|
|
*
|
|
|
|
* In the case that the z3fold page in which the allocation resides is under
|
2022-04-29 06:16:05 +00:00
|
|
|
* reclaim, as indicated by the PAGE_CLAIMED flag being set, this function
|
|
|
|
* only sets the first|middle|last_chunks to 0. The page is actually freed
|
|
|
|
* once all buddies are evicted (see z3fold_reclaim_page() below).
|
2016-05-20 23:58:30 +00:00
|
|
|
*/
|
|
|
|
static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct page *page;
|
|
|
|
enum buddy bud;
|
2019-10-07 00:58:22 +00:00
|
|
|
bool page_claimed;
|
2016-05-20 23:58:30 +00:00
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
zhdr = get_z3fold_header(handle);
|
2016-05-20 23:58:30 +00:00
|
|
|
page = virt_to_page(zhdr);
|
2019-10-07 00:58:22 +00:00
|
|
|
page_claimed = test_and_set_bit(PAGE_CLAIMED, &page->private);
|
2016-05-20 23:58:30 +00:00
|
|
|
|
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private)) {
|
2018-11-16 23:07:56 +00:00
|
|
|
/* if a headless page is under reclaim, just leave.
|
|
|
|
* NB: we use test_and_set_bit for a reason: if the bit
|
|
|
|
* has not been set before, we release this page
|
|
|
|
* immediately so we don't care about its value any more.
|
|
|
|
*/
|
2019-10-07 00:58:22 +00:00
|
|
|
if (!page_claimed) {
|
2019-12-01 01:56:11 +00:00
|
|
|
put_z3fold_header(zhdr);
|
2019-05-14 00:22:52 +00:00
|
|
|
free_z3fold_page(page, true);
|
2018-11-16 23:07:56 +00:00
|
|
|
atomic64_dec(&pool->pages_nr);
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
2018-11-16 23:07:56 +00:00
|
|
|
return;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
2018-11-16 23:07:56 +00:00
|
|
|
/* Non-headless case */
|
|
|
|
bud = handle_to_buddy(handle);
|
|
|
|
|
|
|
|
switch (bud) {
|
|
|
|
case FIRST:
|
|
|
|
zhdr->first_chunks = 0;
|
|
|
|
break;
|
|
|
|
case MIDDLE:
|
|
|
|
zhdr->middle_chunks = 0;
|
|
|
|
break;
|
|
|
|
case LAST:
|
|
|
|
zhdr->last_chunks = 0;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("%s: unknown bud %d\n", __func__, bud);
|
|
|
|
WARN_ON(1);
|
2019-12-01 01:56:11 +00:00
|
|
|
put_z3fold_header(zhdr);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
if (!page_claimed)
|
2020-12-15 03:12:30 +00:00
|
|
|
free_handle(handle, zhdr);
|
2022-04-29 06:16:05 +00:00
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked_list))
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
return;
|
2019-10-07 00:58:22 +00:00
|
|
|
if (page_claimed) {
|
|
|
|
/* the page has not been claimed by us */
|
2022-04-29 06:16:05 +00:00
|
|
|
put_z3fold_header(zhdr);
|
2018-05-11 23:01:46 +00:00
|
|
|
return;
|
|
|
|
}
|
2020-12-15 03:12:33 +00:00
|
|
|
if (test_and_set_bit(NEEDS_COMPACTING, &page->private)) {
|
2019-10-07 00:58:22 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2022-04-29 06:40:43 +00:00
|
|
|
put_z3fold_header(zhdr);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (zhdr->cpu < 0 || !cpu_online(zhdr->cpu)) {
|
|
|
|
zhdr->cpu = -1;
|
2017-11-17 23:26:16 +00:00
|
|
|
kref_get(&zhdr->refcount);
|
2019-10-07 00:58:22 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2019-12-01 01:56:11 +00:00
|
|
|
do_compact_page(zhdr, true);
|
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-06 23:24:47 +00:00
|
|
|
return;
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
2017-11-17 23:26:16 +00:00
|
|
|
kref_get(&zhdr->refcount);
|
2019-10-07 00:58:22 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2019-12-01 01:56:11 +00:00
|
|
|
queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work);
|
|
|
|
put_z3fold_header(zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_map() - maps the allocation associated with the given handle
|
|
|
|
* @pool: pool in which the allocation resides
|
|
|
|
* @handle: handle associated with the allocation to be mapped
|
|
|
|
*
|
|
|
|
* Extracts the buddy number from handle and constructs the pointer to the
|
|
|
|
* correct starting chunk within the page.
|
|
|
|
*
|
|
|
|
* Returns: a pointer to the mapped allocation
|
|
|
|
*/
|
|
|
|
static void *z3fold_map(struct z3fold_pool *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct page *page;
|
|
|
|
void *addr;
|
|
|
|
enum buddy buddy;
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
zhdr = get_z3fold_header(handle);
|
2016-05-20 23:58:30 +00:00
|
|
|
addr = zhdr;
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
buddy = handle_to_buddy(handle);
|
|
|
|
switch (buddy) {
|
|
|
|
case FIRST:
|
|
|
|
addr += ZHDR_SIZE_ALIGNED;
|
|
|
|
break;
|
|
|
|
case MIDDLE:
|
|
|
|
addr += zhdr->start_middle << CHUNK_SHIFT;
|
|
|
|
set_bit(MIDDLE_CHUNK_MAPPED, &page->private);
|
|
|
|
break;
|
|
|
|
case LAST:
|
2018-11-16 23:07:56 +00:00
|
|
|
addr += PAGE_SIZE - (handle_to_chunks(handle) << CHUNK_SHIFT);
|
2016-05-20 23:58:30 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("unknown buddy id %d\n", buddy);
|
|
|
|
WARN_ON(1);
|
|
|
|
addr = NULL;
|
|
|
|
break;
|
|
|
|
}
|
2017-02-24 22:57:23 +00:00
|
|
|
|
2019-05-14 00:22:52 +00:00
|
|
|
if (addr)
|
|
|
|
zhdr->mapped_count++;
|
2016-05-20 23:58:30 +00:00
|
|
|
out:
|
2019-12-01 01:56:11 +00:00
|
|
|
put_z3fold_header(zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_unmap() - unmaps the allocation associated with the given handle
|
|
|
|
* @pool: pool in which the allocation resides
|
|
|
|
* @handle: handle associated with the allocation to be unmapped
|
|
|
|
*/
|
|
|
|
static void z3fold_unmap(struct z3fold_pool *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct page *page;
|
|
|
|
enum buddy buddy;
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
zhdr = get_z3fold_header(handle);
|
2016-05-20 23:58:30 +00:00
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
|
2017-02-24 22:57:23 +00:00
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
2016-05-20 23:58:30 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
buddy = handle_to_buddy(handle);
|
|
|
|
if (buddy == MIDDLE)
|
|
|
|
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
|
2019-05-14 00:22:52 +00:00
|
|
|
zhdr->mapped_count--;
|
2019-12-01 01:56:11 +00:00
|
|
|
put_z3fold_header(zhdr);
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_get_pool_size() - gets the z3fold pool size in pages
|
|
|
|
* @pool: pool whose size is being queried
|
|
|
|
*
|
2017-02-24 22:57:15 +00:00
|
|
|
* Returns: size in pages of the given pool.
|
2016-05-20 23:58:30 +00:00
|
|
|
*/
|
|
|
|
static u64 z3fold_get_pool_size(struct z3fold_pool *pool)
|
|
|
|
{
|
2017-02-24 22:57:15 +00:00
|
|
|
return atomic64_read(&pool->pages_nr);
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
2019-05-14 00:22:52 +00:00
|
|
|
static bool z3fold_page_isolate(struct page *page, isolate_mode_t mode)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct z3fold_pool *pool;
|
|
|
|
|
|
|
|
VM_BUG_ON_PAGE(PageIsolated(page), page);
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
2019-05-14 00:22:52 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
zhdr = page_address(page);
|
|
|
|
z3fold_page_lock(zhdr);
|
|
|
|
if (test_bit(NEEDS_COMPACTING, &page->private) ||
|
|
|
|
test_bit(PAGE_STALE, &page->private))
|
|
|
|
goto out;
|
|
|
|
|
2019-12-01 01:56:11 +00:00
|
|
|
if (zhdr->mapped_count != 0 || zhdr->foreign_handles != 0)
|
|
|
|
goto out;
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
if (test_and_set_bit(PAGE_CLAIMED, &page->private))
|
|
|
|
goto out;
|
2019-05-14 00:22:52 +00:00
|
|
|
pool = zhdr_to_pool(zhdr);
|
2019-12-01 01:56:11 +00:00
|
|
|
spin_lock(&pool->lock);
|
|
|
|
if (!list_empty(&zhdr->buddy))
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return true;
|
2019-05-14 00:22:52 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-06-07 19:38:48 +00:00
|
|
|
static int z3fold_page_migrate(struct page *newpage, struct page *page,
|
|
|
|
enum migrate_mode mode)
|
2019-05-14 00:22:52 +00:00
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr, *new_zhdr;
|
|
|
|
struct z3fold_pool *pool;
|
|
|
|
|
|
|
|
VM_BUG_ON_PAGE(!PageIsolated(page), page);
|
2020-12-15 03:12:33 +00:00
|
|
|
VM_BUG_ON_PAGE(!test_bit(PAGE_CLAIMED, &page->private), page);
|
2019-07-12 03:52:14 +00:00
|
|
|
VM_BUG_ON_PAGE(!PageLocked(newpage), newpage);
|
2019-05-14 00:22:52 +00:00
|
|
|
|
|
|
|
zhdr = page_address(page);
|
|
|
|
pool = zhdr_to_pool(zhdr);
|
|
|
|
|
2020-12-15 03:12:33 +00:00
|
|
|
if (!z3fold_page_trylock(zhdr))
|
2019-05-14 00:22:52 +00:00
|
|
|
return -EAGAIN;
|
2019-12-01 01:56:11 +00:00
|
|
|
if (zhdr->mapped_count != 0 || zhdr->foreign_handles != 0) {
|
2020-12-15 03:12:33 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2022-04-29 06:40:43 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
2019-05-14 00:22:52 +00:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
2019-07-16 23:26:21 +00:00
|
|
|
if (work_pending(&zhdr->work)) {
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
2019-05-14 00:22:52 +00:00
|
|
|
new_zhdr = page_address(newpage);
|
|
|
|
memcpy(new_zhdr, zhdr, PAGE_SIZE);
|
|
|
|
newpage->private = page->private;
|
2022-04-29 06:40:43 +00:00
|
|
|
set_bit(PAGE_MIGRATED, &page->private);
|
2019-05-14 00:22:52 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
spin_lock_init(&new_zhdr->page_lock);
|
2019-07-16 23:26:21 +00:00
|
|
|
INIT_WORK(&new_zhdr->work, compact_page_work);
|
|
|
|
/*
|
|
|
|
* z3fold_page_isolate() ensures that new_zhdr->buddy is empty,
|
|
|
|
* so we only have to reinitialize it.
|
|
|
|
*/
|
|
|
|
INIT_LIST_HEAD(&new_zhdr->buddy);
|
2019-05-14 00:22:52 +00:00
|
|
|
__ClearPageMovable(page);
|
|
|
|
|
|
|
|
get_page(newpage);
|
|
|
|
z3fold_page_lock(new_zhdr);
|
|
|
|
if (new_zhdr->first_chunks)
|
|
|
|
encode_handle(new_zhdr, FIRST);
|
|
|
|
if (new_zhdr->last_chunks)
|
|
|
|
encode_handle(new_zhdr, LAST);
|
|
|
|
if (new_zhdr->middle_chunks)
|
|
|
|
encode_handle(new_zhdr, MIDDLE);
|
|
|
|
set_bit(NEEDS_COMPACTING, &newpage->private);
|
|
|
|
new_zhdr->cpu = smp_processor_id();
|
2022-06-07 19:38:48 +00:00
|
|
|
__SetPageMovable(newpage, &z3fold_mops);
|
2019-05-14 00:22:52 +00:00
|
|
|
z3fold_page_unlock(new_zhdr);
|
|
|
|
|
|
|
|
queue_work_on(new_zhdr->cpu, pool->compact_wq, &new_zhdr->work);
|
|
|
|
|
2022-04-29 06:40:43 +00:00
|
|
|
/* PAGE_CLAIMED and PAGE_MIGRATED are cleared now. */
|
|
|
|
page->private = 0;
|
2019-05-14 00:22:52 +00:00
|
|
|
put_page(page);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void z3fold_page_putback(struct page *page)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct z3fold_pool *pool;
|
|
|
|
|
|
|
|
zhdr = page_address(page);
|
|
|
|
pool = zhdr_to_pool(zhdr);
|
|
|
|
|
|
|
|
z3fold_page_lock(zhdr);
|
|
|
|
if (!list_empty(&zhdr->buddy))
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
INIT_LIST_HEAD(&page->lru);
|
2022-04-29 06:16:05 +00:00
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked))
|
2019-05-14 00:22:52 +00:00
|
|
|
return;
|
2022-04-29 06:40:43 +00:00
|
|
|
if (list_empty(&zhdr->buddy))
|
|
|
|
add_to_unbuddied(pool, zhdr);
|
2020-12-15 03:12:33 +00:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2019-05-14 00:22:52 +00:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
|
|
|
|
2022-06-07 19:38:48 +00:00
|
|
|
static const struct movable_operations z3fold_mops = {
|
2019-05-14 00:22:52 +00:00
|
|
|
.isolate_page = z3fold_page_isolate,
|
2022-06-07 19:38:48 +00:00
|
|
|
.migrate_page = z3fold_page_migrate,
|
2019-05-14 00:22:52 +00:00
|
|
|
.putback_page = z3fold_page_putback,
|
|
|
|
};
|
|
|
|
|
2016-05-20 23:58:30 +00:00
|
|
|
/*****************
|
|
|
|
* zpool
|
|
|
|
****************/
|
|
|
|
|
2023-06-12 09:38:13 +00:00
|
|
|
static void *z3fold_zpool_create(const char *name, gfp_t gfp)
|
2016-05-20 23:58:30 +00:00
|
|
|
{
|
2023-06-12 09:38:11 +00:00
|
|
|
return z3fold_create_pool(name, gfp);
|
2016-05-20 23:58:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void z3fold_zpool_destroy(void *pool)
|
|
|
|
{
|
|
|
|
z3fold_destroy_pool(pool);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int z3fold_zpool_malloc(void *pool, size_t size, gfp_t gfp,
|
|
|
|
unsigned long *handle)
|
|
|
|
{
|
|
|
|
return z3fold_alloc(pool, size, gfp, handle);
|
|
|
|
}
|
|
|
|
static void z3fold_zpool_free(void *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
z3fold_free(pool, handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *z3fold_zpool_map(void *pool, unsigned long handle,
|
|
|
|
enum zpool_mapmode mm)
|
|
|
|
{
|
|
|
|
return z3fold_map(pool, handle);
|
|
|
|
}
|
|
|
|
static void z3fold_zpool_unmap(void *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
z3fold_unmap(pool, handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 z3fold_zpool_total_size(void *pool)
|
|
|
|
{
|
|
|
|
return z3fold_get_pool_size(pool) * PAGE_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct zpool_driver z3fold_zpool_driver = {
|
|
|
|
.type = "z3fold",
|
2021-02-26 01:18:22 +00:00
|
|
|
.sleep_mapped = true,
|
2016-05-20 23:58:30 +00:00
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.create = z3fold_zpool_create,
|
|
|
|
.destroy = z3fold_zpool_destroy,
|
|
|
|
.malloc = z3fold_zpool_malloc,
|
|
|
|
.free = z3fold_zpool_free,
|
|
|
|
.map = z3fold_zpool_map,
|
|
|
|
.unmap = z3fold_zpool_unmap,
|
|
|
|
.total_size = z3fold_zpool_total_size,
|
|
|
|
};
|
|
|
|
|
|
|
|
MODULE_ALIAS("zpool-z3fold");
|
|
|
|
|
|
|
|
static int __init init_z3fold(void)
|
|
|
|
{
|
2021-07-01 01:50:27 +00:00
|
|
|
/*
|
|
|
|
* Make sure the z3fold header is not larger than the page size and
|
|
|
|
* there has remaining spaces for its buddy.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(ZHDR_SIZE_ALIGNED > PAGE_SIZE - CHUNK_SIZE);
|
2016-05-20 23:58:30 +00:00
|
|
|
zpool_register_driver(&z3fold_zpool_driver);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit exit_z3fold(void)
|
|
|
|
{
|
|
|
|
zpool_unregister_driver(&z3fold_zpool_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(init_z3fold);
|
|
|
|
module_exit(exit_z3fold);
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_AUTHOR("Vitaly Wool <vitalywool@gmail.com>");
|
|
|
|
MODULE_DESCRIPTION("3-Fold Allocator for Compressed Pages");
|