2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
#include <linux/sched.h>
|
2019-05-14 03:22:52 +03:00
|
|
|
#include <linux/cpumask.h>
|
|
|
|
#include <linux/dcache.h>
|
2016-05-21 02:58:30 +03:00
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/module.h>
|
2019-05-14 03:22:52 +03: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-07 02:24:47 +03:00
|
|
|
#include <linux/percpu.h>
|
2019-05-14 03:22:52 +03:00
|
|
|
#include <linux/mount.h>
|
|
|
|
#include <linux/fs.h>
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
#include <linux/workqueue.h>
|
2016-05-21 02:58:30 +03:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/zpool.h>
|
|
|
|
|
2019-05-14 03:22:49 +03: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)
|
|
|
|
#define NCHUNKS ((PAGE_SIZE - ZHDR_SIZE_ALIGNED) >> CHUNK_SHIFT)
|
|
|
|
|
|
|
|
#define BUDDY_MASK (0x3)
|
|
|
|
#define BUDDY_SHIFT 2
|
|
|
|
#define SLOTS_ALIGN (0x40)
|
|
|
|
|
2016-05-21 02:58:30 +03:00
|
|
|
/*****************
|
|
|
|
* Structures
|
|
|
|
*****************/
|
2017-02-25 01:57:17 +03:00
|
|
|
struct z3fold_pool;
|
|
|
|
struct z3fold_ops {
|
|
|
|
int (*evict)(struct z3fold_pool *pool, unsigned long handle);
|
|
|
|
};
|
|
|
|
|
|
|
|
enum buddy {
|
|
|
|
HEADLESS = 0,
|
|
|
|
FIRST,
|
|
|
|
MIDDLE,
|
|
|
|
LAST,
|
2019-05-14 03:22:49 +03: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];
|
|
|
|
unsigned long pool; /* back link + flags */
|
2017-02-25 01:57:17 +03:00
|
|
|
};
|
2019-05-14 03:22:49 +03:00
|
|
|
#define HANDLE_FLAG_MASK (0x03)
|
2017-02-25 01:57:17 +03: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-07 02:24:47 +03:00
|
|
|
* struct z3fold_header - z3fold page metadata occupying first chunks of each
|
2017-02-25 01:57:17 +03: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-07 02:24:47 +03:00
|
|
|
* @buddy: links the z3fold page into the relevant list in the
|
|
|
|
* pool
|
2017-02-25 01:57:23 +03: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-07 02:24:47 +03:00
|
|
|
* @refcount: reference count for the z3fold page
|
|
|
|
* @work: work_struct for page layout optimization
|
2019-05-14 03:22:49 +03:00
|
|
|
* @slots: pointer to the structure holding buddy slots
|
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-07 02:24:47 +03:00
|
|
|
* @cpu: CPU which this page "belongs" to
|
2017-02-25 01:57:17 +03: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 03:22:52 +03:00
|
|
|
* @mapped_count: the number of objects currently mapped
|
2017-02-25 01:57:17 +03:00
|
|
|
*/
|
|
|
|
struct z3fold_header {
|
|
|
|
struct list_head buddy;
|
2017-02-25 01:57:23 +03:00
|
|
|
spinlock_t page_lock;
|
2017-02-25 01:57:26 +03: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-07 02:24:47 +03:00
|
|
|
struct work_struct work;
|
2019-05-14 03:22:49 +03:00
|
|
|
struct z3fold_buddy_slots *slots;
|
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-07 02:24:47 +03:00
|
|
|
short cpu;
|
2017-02-25 01:57:17 +03: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 03:22:52 +03:00
|
|
|
unsigned short mapped_count:2;
|
2017-02-25 01:57:17 +03:00
|
|
|
};
|
|
|
|
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
* @name: pool name
|
|
|
|
* @lock: protects pool unbuddied/lru lists
|
|
|
|
* @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.
|
2016-05-21 02:58:30 +03:00
|
|
|
* @lru: list tracking the z3fold pages in LRU order by most recently
|
|
|
|
* added 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-07 02:24:47 +03:00
|
|
|
* @stale: list of pages marked for freeing
|
2016-05-21 02:58:30 +03:00
|
|
|
* @pages_nr: number of z3fold pages in the pool.
|
2019-05-14 03:22:49 +03:00
|
|
|
* @c_handle: cache for z3fold_buddy_slots allocation
|
2016-05-21 02:58:30 +03:00
|
|
|
* @ops: pointer to a structure of user defined operations specified at
|
|
|
|
* pool creation time.
|
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-07 02:24:47 +03:00
|
|
|
* @compact_wq: workqueue for page layout background optimization
|
|
|
|
* @release_wq: workqueue for safe page release
|
|
|
|
* @work: work_struct for safe page release
|
2019-05-14 03:22:52 +03:00
|
|
|
* @inode: inode for z3fold pseudo filesystem
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
const char *name;
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
spinlock_t stale_lock;
|
|
|
|
struct list_head *unbuddied;
|
2016-05-21 02:58:30 +03:00
|
|
|
struct list_head lru;
|
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-07 02:24:47 +03:00
|
|
|
struct list_head stale;
|
2017-02-25 01:57:15 +03:00
|
|
|
atomic64_t pages_nr;
|
2019-05-14 03:22:49 +03:00
|
|
|
struct kmem_cache *c_handle;
|
2016-05-21 02:58:30 +03:00
|
|
|
const struct z3fold_ops *ops;
|
|
|
|
struct zpool *zpool;
|
|
|
|
const struct zpool_ops *zpool_ops;
|
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-07 02:24:47 +03:00
|
|
|
struct workqueue_struct *compact_wq;
|
|
|
|
struct workqueue_struct *release_wq;
|
|
|
|
struct work_struct work;
|
2019-05-14 03:22:52 +03:00
|
|
|
struct inode *inode;
|
2016-05-21 02:58:30 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal z3fold page flags
|
|
|
|
*/
|
|
|
|
enum z3fold_page_flags {
|
2017-02-25 01:57:26 +03:00
|
|
|
PAGE_HEADLESS = 0,
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
NEEDS_COMPACTING,
|
2018-05-12 02:01:46 +03:00
|
|
|
PAGE_STALE,
|
2018-11-17 02:07:56 +03:00
|
|
|
PAGE_CLAIMED, /* by either reclaim or free */
|
2016-05-21 02:58:30 +03: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)++)
|
|
|
|
|
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-07 02:24:47 +03:00
|
|
|
static void compact_page_work(struct work_struct *w);
|
|
|
|
|
2019-05-14 03:22:49 +03:00
|
|
|
static inline struct z3fold_buddy_slots *alloc_slots(struct z3fold_pool *pool)
|
|
|
|
{
|
|
|
|
struct z3fold_buddy_slots *slots = kmem_cache_alloc(pool->c_handle,
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
|
|
|
if (slots) {
|
|
|
|
memset(slots->slot, 0, sizeof(slots->slot));
|
|
|
|
slots->pool = (unsigned long)pool;
|
|
|
|
}
|
|
|
|
|
|
|
|
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));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void free_handle(unsigned long handle)
|
|
|
|
{
|
|
|
|
struct z3fold_buddy_slots *slots;
|
|
|
|
int i;
|
|
|
|
bool is_free;
|
|
|
|
|
|
|
|
if (handle & (1 << PAGE_HEADLESS))
|
|
|
|
return;
|
|
|
|
|
|
|
|
WARN_ON(*(unsigned long *)handle == 0);
|
|
|
|
*(unsigned long *)handle = 0;
|
|
|
|
slots = handle_to_slots(handle);
|
|
|
|
is_free = true;
|
|
|
|
for (i = 0; i <= BUDDY_MASK; i++) {
|
|
|
|
if (slots->slot[i]) {
|
|
|
|
is_free = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_free) {
|
|
|
|
struct z3fold_pool *pool = slots_to_pool(slots);
|
|
|
|
|
|
|
|
kmem_cache_free(pool->c_handle, slots);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
static struct dentry *z3fold_do_mount(struct file_system_type *fs_type,
|
|
|
|
int flags, const char *dev_name, void *data)
|
|
|
|
{
|
2019-05-20 15:44:57 +03:00
|
|
|
return mount_pseudo(fs_type, NULL, NULL, 0x33);
|
2019-05-14 03:22:52 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct file_system_type z3fold_fs = {
|
|
|
|
.name = "z3fold",
|
|
|
|
.mount = z3fold_do_mount,
|
|
|
|
.kill_sb = kill_anon_super,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct vfsmount *z3fold_mnt;
|
|
|
|
static int z3fold_mount(void)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
z3fold_mnt = kern_mount(&z3fold_fs);
|
|
|
|
if (IS_ERR(z3fold_mnt))
|
|
|
|
ret = PTR_ERR(z3fold_mnt);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void z3fold_unmount(void)
|
|
|
|
{
|
|
|
|
kern_unmount(z3fold_mnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct address_space_operations z3fold_aops;
|
|
|
|
static int z3fold_register_migration(struct z3fold_pool *pool)
|
|
|
|
{
|
|
|
|
pool->inode = alloc_anon_inode(z3fold_mnt->mnt_sb);
|
|
|
|
if (IS_ERR(pool->inode)) {
|
|
|
|
pool->inode = NULL;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
pool->inode->i_mapping->private_data = pool;
|
|
|
|
pool->inode->i_mapping->a_ops = &z3fold_aops;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void z3fold_unregister_migration(struct z3fold_pool *pool)
|
|
|
|
{
|
|
|
|
if (pool->inode)
|
|
|
|
iput(pool->inode);
|
|
|
|
}
|
|
|
|
|
2016-05-21 02:58:30 +03:00
|
|
|
/* Initializes the z3fold header of a newly allocated z3fold page */
|
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-07 02:24:47 +03:00
|
|
|
static struct z3fold_header *init_z3fold_page(struct page *page,
|
|
|
|
struct z3fold_pool *pool)
|
2016-05-21 02:58:30 +03:00
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = page_address(page);
|
2019-05-14 03:22:49 +03:00
|
|
|
struct z3fold_buddy_slots *slots = alloc_slots(pool);
|
|
|
|
|
|
|
|
if (!slots)
|
|
|
|
return NULL;
|
2016-05-21 02:58:30 +03:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&page->lru);
|
|
|
|
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-07 02:24:47 +03:00
|
|
|
clear_bit(NEEDS_COMPACTING, &page->private);
|
|
|
|
clear_bit(PAGE_STALE, &page->private);
|
2018-11-17 02:07:56 +03:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2016-05-21 02:58:30 +03:00
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
spin_lock_init(&zhdr->page_lock);
|
2017-02-25 01:57:26 +03:00
|
|
|
kref_init(&zhdr->refcount);
|
2016-05-21 02:58:30 +03:00
|
|
|
zhdr->first_chunks = 0;
|
|
|
|
zhdr->middle_chunks = 0;
|
|
|
|
zhdr->last_chunks = 0;
|
|
|
|
zhdr->first_num = 0;
|
|
|
|
zhdr->start_middle = 0;
|
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-07 02:24:47 +03:00
|
|
|
zhdr->cpu = -1;
|
2019-05-14 03:22:49 +03:00
|
|
|
zhdr->slots = slots;
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
INIT_WORK(&zhdr->work, compact_page_work);
|
2016-05-21 02:58:30 +03:00
|
|
|
return zhdr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Resets the struct page fields and frees the page */
|
2019-05-14 03:22:52 +03:00
|
|
|
static void free_z3fold_page(struct page *page, bool headless)
|
2016-05-21 02:58:30 +03:00
|
|
|
{
|
2019-05-14 03:22:52 +03:00
|
|
|
if (!headless) {
|
|
|
|
lock_page(page);
|
|
|
|
__ClearPageMovable(page);
|
|
|
|
unlock_page(page);
|
|
|
|
}
|
|
|
|
ClearPagePrivate(page);
|
2017-02-25 01:57:26 +03:00
|
|
|
__free_page(page);
|
|
|
|
}
|
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
/* Lock a z3fold page */
|
|
|
|
static inline void z3fold_page_lock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
spin_lock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
2017-04-14 00:56:14 +03:00
|
|
|
/* Try to lock a z3fold page */
|
|
|
|
static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
return spin_trylock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
/* Unlock a z3fold page */
|
|
|
|
static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
|
|
|
|
{
|
|
|
|
spin_unlock(&zhdr->page_lock);
|
|
|
|
}
|
|
|
|
|
2019-05-14 03:22:49 +03: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-21 02:58:30 +03:00
|
|
|
/*
|
|
|
|
* Encodes the handle of a particular buddy within a z3fold page
|
|
|
|
* Pool lock should be held as this function accesses first_num
|
|
|
|
*/
|
|
|
|
static unsigned long encode_handle(struct z3fold_header *zhdr, enum buddy bud)
|
|
|
|
{
|
2019-05-14 03:22:49 +03:00
|
|
|
struct z3fold_buddy_slots *slots;
|
|
|
|
unsigned long h = (unsigned long)zhdr;
|
|
|
|
int idx = 0;
|
2016-05-21 02:58:30 +03:00
|
|
|
|
2019-05-14 03:22:49 +03: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);
|
|
|
|
|
|
|
|
slots = zhdr->slots;
|
|
|
|
slots->slot[idx] = h;
|
|
|
|
return (unsigned long)&slots->slot[idx];
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Returns the z3fold page where a given handle is stored */
|
2019-05-14 03:22:52 +03:00
|
|
|
static inline struct z3fold_header *handle_to_z3fold_header(unsigned long h)
|
2016-05-21 02:58:30 +03:00
|
|
|
{
|
2019-05-14 03:22:52 +03:00
|
|
|
unsigned long addr = h;
|
2019-05-14 03:22:49 +03:00
|
|
|
|
|
|
|
if (!(addr & (1 << PAGE_HEADLESS)))
|
2019-05-14 03:22:52 +03:00
|
|
|
addr = *(unsigned long *)h;
|
2019-05-14 03:22:49 +03:00
|
|
|
|
|
|
|
return (struct z3fold_header *)(addr & PAGE_MASK);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
2018-11-17 02:07:56 +03:00
|
|
|
/* only for LAST bud, returns zero otherwise */
|
|
|
|
static unsigned short handle_to_chunks(unsigned long handle)
|
|
|
|
{
|
2019-05-14 03:22:49 +03:00
|
|
|
unsigned long addr = *(unsigned long *)handle;
|
|
|
|
|
|
|
|
return (addr & ~PAGE_MASK) >> BUDDY_SHIFT;
|
2018-11-17 02:07:56 +03:00
|
|
|
}
|
|
|
|
|
2017-02-23 02:46:51 +03: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-21 02:58:30 +03:00
|
|
|
static enum buddy handle_to_buddy(unsigned long handle)
|
|
|
|
{
|
2019-05-14 03:22:49 +03:00
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
unsigned long addr;
|
|
|
|
|
|
|
|
WARN_ON(handle & (1 << PAGE_HEADLESS));
|
|
|
|
addr = *(unsigned long *)handle;
|
|
|
|
zhdr = (struct z3fold_header *)(addr & PAGE_MASK);
|
|
|
|
return (addr - zhdr->first_num) & BUDDY_MASK;
|
2016-05-21 02:58:30 +03: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 03:22:43 +03:00
|
|
|
static inline struct z3fold_pool *zhdr_to_pool(struct z3fold_header *zhdr)
|
|
|
|
{
|
2019-05-14 03:22:49 +03:00
|
|
|
return slots_to_pool(zhdr->slots);
|
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 03:22:43 +03: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-07 02:24:47 +03: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 03:22:43 +03: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-07 02:24:47 +03:00
|
|
|
|
|
|
|
WARN_ON(!list_empty(&zhdr->buddy));
|
|
|
|
set_bit(PAGE_STALE, &page->private);
|
2017-10-04 02:15:06 +03: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-07 02:24:47 +03:00
|
|
|
spin_lock(&pool->lock);
|
|
|
|
if (!list_empty(&page->lru))
|
2019-05-14 03:22:52 +03:00
|
|
|
list_del_init(&page->lru);
|
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-07 02:24:47 +03:00
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
if (locked)
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
list_add(&zhdr->buddy, &pool->stale);
|
|
|
|
queue_work(pool->release_wq, &pool->work);
|
|
|
|
spin_unlock(&pool->stale_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __attribute__((__unused__))
|
|
|
|
release_z3fold_page(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
|
|
|
|
refcount);
|
|
|
|
__release_z3fold_page(zhdr, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
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 03:22:43 +03:00
|
|
|
struct z3fold_pool *pool = zhdr_to_pool(zhdr);
|
|
|
|
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-07 02:24:47 +03: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 03:22:43 +03: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-07 02:24:47 +03: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 03:22:52 +03: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-07 02:24:47 +03:00
|
|
|
cond_resched();
|
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
}
|
|
|
|
spin_unlock(&pool->stale_lock);
|
|
|
|
}
|
|
|
|
|
2016-05-21 02:58:30 +03: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-25 01:57:17 +03:00
|
|
|
0 : zhdr->start_middle - ZHDR_CHUNKS;
|
2016-05-21 02:58:30 +03:00
|
|
|
int nfree_after = zhdr->last_chunks ?
|
2017-02-25 01:57:17 +03:00
|
|
|
0 : TOTAL_CHUNKS -
|
|
|
|
(zhdr->start_middle + zhdr->middle_chunks);
|
2016-05-21 02:58:30 +03: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 03:22:43 +03: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) {
|
|
|
|
struct list_head *unbuddied = get_cpu_ptr(pool->unbuddied);
|
|
|
|
|
|
|
|
int freechunks = num_free_chunks(zhdr);
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&zhdr->buddy, &unbuddied[freechunks]);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
zhdr->cpu = smp_processor_id();
|
|
|
|
put_cpu_ptr(pool->unbuddied);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-25 01:57:17 +03: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);
|
|
|
|
}
|
|
|
|
|
2017-02-25 01:57:20 +03:00
|
|
|
#define BIG_CHUNK_GAP 3
|
2016-05-21 02:58:30 +03: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-25 01:57:17 +03:00
|
|
|
if (test_bit(MIDDLE_CHUNK_MAPPED, &page->private))
|
|
|
|
return 0; /* can't move middle chunk, it's used */
|
2016-05-21 02:58:30 +03:00
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
if (unlikely(PageIsolated(page)))
|
|
|
|
return 0;
|
|
|
|
|
2017-02-25 01:57:17 +03: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-21 02:58:30 +03:00
|
|
|
zhdr->first_chunks = zhdr->middle_chunks;
|
|
|
|
zhdr->middle_chunks = 0;
|
|
|
|
zhdr->start_middle = 0;
|
|
|
|
zhdr->first_num++;
|
2017-02-25 01:57:20 +03:00
|
|
|
return 1;
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
2017-02-25 01:57:20 +03: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-21 02:58:30 +03: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-07 02:24:47 +03: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 03:22:43 +03: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-07 02:24:47 +03:00
|
|
|
struct page *page;
|
|
|
|
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
if (locked)
|
|
|
|
WARN_ON(z3fold_page_trylock(zhdr));
|
|
|
|
else
|
|
|
|
z3fold_page_lock(zhdr);
|
2017-11-18 02:26:16 +03: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-07 02:24:47 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
2017-11-18 02:26:16 +03:00
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
|
|
|
|
atomic64_dec(&pool->pages_nr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
if (unlikely(PageIsolated(page) ||
|
|
|
|
test_bit(PAGE_STALE, &page->private))) {
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
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-07 02:24:47 +03: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 03:22:43 +03:00
|
|
|
add_to_unbuddied(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-07 02:24:47 +03: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 03:22:43 +03: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:
|
|
|
|
/* First, try to find an unbuddied z3fold page. */
|
|
|
|
unbuddied = get_cpu_ptr(pool->unbuddied);
|
|
|
|
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);
|
|
|
|
l = &unbuddied[i];
|
|
|
|
if (unlikely(zhdr != list_first_entry(READ_ONCE(l),
|
|
|
|
struct z3fold_header, buddy)) ||
|
|
|
|
!z3fold_page_trylock(zhdr)) {
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
zhdr = NULL;
|
|
|
|
put_cpu_ptr(pool->unbuddied);
|
|
|
|
if (can_sleep)
|
|
|
|
cond_resched();
|
|
|
|
goto lookup;
|
|
|
|
}
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
zhdr->cpu = -1;
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
if (test_bit(NEEDS_COMPACTING, &page->private)) {
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
zhdr = NULL;
|
|
|
|
put_cpu_ptr(pool->unbuddied);
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
put_cpu_ptr(pool->unbuddied);
|
|
|
|
|
2019-05-14 03:22:46 +03: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);
|
|
|
|
if (test_bit(NEEDS_COMPACTING, &page->private)) {
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
zhdr = NULL;
|
|
|
|
if (can_sleep)
|
|
|
|
cond_resched();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 03:22:43 +03:00
|
|
|
return 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-07 02:24:47 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* API Functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_create_pool() - create a new z3fold pool
|
|
|
|
* @name: pool name
|
|
|
|
* @gfp: gfp flags when allocating the z3fold pool structure
|
|
|
|
* @ops: user-defined operations for the z3fold pool
|
|
|
|
*
|
|
|
|
* Return: pointer to the new z3fold pool or NULL if the metadata allocation
|
|
|
|
* failed.
|
|
|
|
*/
|
|
|
|
static struct z3fold_pool *z3fold_create_pool(const char *name, gfp_t gfp,
|
|
|
|
const struct z3fold_ops *ops)
|
|
|
|
{
|
|
|
|
struct z3fold_pool *pool = NULL;
|
|
|
|
int i, cpu;
|
|
|
|
|
|
|
|
pool = kzalloc(sizeof(struct z3fold_pool), gfp);
|
|
|
|
if (!pool)
|
|
|
|
goto out;
|
2019-05-14 03:22:49 +03: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-07 02:24:47 +03:00
|
|
|
spin_lock_init(&pool->lock);
|
|
|
|
spin_lock_init(&pool->stale_lock);
|
|
|
|
pool->unbuddied = __alloc_percpu(sizeof(struct list_head)*NCHUNKS, 2);
|
2018-04-11 02:29:34 +03: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-07 02:24:47 +03: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->lru);
|
|
|
|
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-11 02:29:34 +03: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-07 02:24:47 +03:00
|
|
|
pool->release_wq = create_singlethread_workqueue(pool->name);
|
|
|
|
if (!pool->release_wq)
|
|
|
|
goto out_wq;
|
2019-05-14 03:22:52 +03:00
|
|
|
if (z3fold_register_migration(pool))
|
|
|
|
goto out_rwq;
|
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-07 02:24:47 +03:00
|
|
|
INIT_WORK(&pool->work, free_pages_work);
|
|
|
|
pool->ops = ops;
|
|
|
|
return pool;
|
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
out_rwq:
|
|
|
|
destroy_workqueue(pool->release_wq);
|
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-07 02:24:47 +03:00
|
|
|
out_wq:
|
|
|
|
destroy_workqueue(pool->compact_wq);
|
2018-04-11 02:29:34 +03:00
|
|
|
out_unbuddied:
|
|
|
|
free_percpu(pool->unbuddied);
|
|
|
|
out_pool:
|
2019-05-14 03:22:49 +03: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-07 02:24:47 +03:00
|
|
|
kfree(pool);
|
2018-04-11 02:29:34 +03: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-07 02:24:47 +03: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 03:22:49 +03:00
|
|
|
kmem_cache_destroy(pool->c_handle);
|
2019-05-14 03:22:52 +03:00
|
|
|
z3fold_unregister_migration(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-07 02:24:47 +03:00
|
|
|
destroy_workqueue(pool->release_wq);
|
|
|
|
destroy_workqueue(pool->compact_wq);
|
|
|
|
kfree(pool);
|
|
|
|
}
|
|
|
|
|
2016-05-21 02:58:30 +03: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.
|
|
|
|
*
|
|
|
|
* gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
|
|
|
|
* as z3fold pool pages.
|
|
|
|
*
|
|
|
|
* 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 03:22:43 +03:00
|
|
|
int chunks = size_to_chunks(size);
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
struct page *page = NULL;
|
2016-05-21 02:58:30 +03:00
|
|
|
enum buddy bud;
|
2018-04-11 02:29:37 +03:00
|
|
|
bool can_sleep = gfpflags_allow_blocking(gfp);
|
2016-05-21 02:58:30 +03:00
|
|
|
|
|
|
|
if (!size || (gfp & __GFP_HIGHMEM))
|
|
|
|
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 03:22:43 +03: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-07 02:24:47 +03:00
|
|
|
if (zhdr) {
|
2017-02-25 01:57:23 +03:00
|
|
|
if (zhdr->first_chunks == 0) {
|
|
|
|
if (zhdr->middle_chunks != 0 &&
|
|
|
|
chunks >= zhdr->start_middle)
|
2016-05-21 02:58:30 +03:00
|
|
|
bud = LAST;
|
2017-02-25 01:57:23 +03:00
|
|
|
else
|
|
|
|
bud = FIRST;
|
|
|
|
} else if (zhdr->last_chunks == 0)
|
|
|
|
bud = LAST;
|
|
|
|
else if (zhdr->middle_chunks == 0)
|
|
|
|
bud = MIDDLE;
|
|
|
|
else {
|
2017-02-25 01:57:26 +03: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-07 02:24:47 +03:00
|
|
|
release_z3fold_page_locked))
|
2017-02-25 01:57:26 +03: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-07 02:24:47 +03:00
|
|
|
else
|
|
|
|
z3fold_page_unlock(zhdr);
|
2017-02-25 01:57:23 +03: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 03:22:43 +03:00
|
|
|
goto retry;
|
2016-05-21 02:58:30 +03: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 03:22:43 +03:00
|
|
|
page = virt_to_page(zhdr);
|
2017-02-25 01:57:23 +03:00
|
|
|
goto found;
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
bud = FIRST;
|
|
|
|
}
|
|
|
|
|
2018-04-06 02:23:32 +03:00
|
|
|
page = NULL;
|
|
|
|
if (can_sleep) {
|
|
|
|
spin_lock(&pool->stale_lock);
|
|
|
|
zhdr = list_first_entry_or_null(&pool->stale,
|
|
|
|
struct z3fold_header, buddy);
|
|
|
|
/*
|
|
|
|
* Before allocating a page, let's see if we can take one from
|
|
|
|
* the stale pages list. cancel_work_sync() can sleep so we
|
|
|
|
* limit this case to the contexts where we can sleep
|
|
|
|
*/
|
|
|
|
if (zhdr) {
|
|
|
|
list_del(&zhdr->buddy);
|
|
|
|
spin_unlock(&pool->stale_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-07 02:24:47 +03:00
|
|
|
cancel_work_sync(&zhdr->work);
|
2018-04-06 02:23:32 +03:00
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
} else {
|
|
|
|
spin_unlock(&pool->stale_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-07 02:24:47 +03:00
|
|
|
}
|
2018-04-06 02:23:32 +03:00
|
|
|
if (!page)
|
|
|
|
page = alloc_page(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-07 02:24:47 +03:00
|
|
|
|
2016-05-21 02:58:30 +03:00
|
|
|
if (!page)
|
|
|
|
return -ENOMEM;
|
2017-02-25 01:57:23 +03: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-07 02:24:47 +03:00
|
|
|
zhdr = init_z3fold_page(page, 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 03:22:43 +03:00
|
|
|
if (!zhdr) {
|
|
|
|
__free_page(page);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
atomic64_inc(&pool->pages_nr);
|
2016-05-21 02:58:30 +03:00
|
|
|
|
|
|
|
if (bud == HEADLESS) {
|
|
|
|
set_bit(PAGE_HEADLESS, &page->private);
|
|
|
|
goto headless;
|
|
|
|
}
|
2019-05-14 03:22:52 +03:00
|
|
|
__SetPageMovable(page, pool->inode->i_mapping);
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_lock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
|
|
|
|
found:
|
|
|
|
if (bud == FIRST)
|
|
|
|
zhdr->first_chunks = chunks;
|
|
|
|
else if (bud == LAST)
|
|
|
|
zhdr->last_chunks = chunks;
|
|
|
|
else {
|
|
|
|
zhdr->middle_chunks = chunks;
|
2017-02-25 01:57:17 +03:00
|
|
|
zhdr->start_middle = zhdr->first_chunks + ZHDR_CHUNKS;
|
2016-05-21 02:58:30 +03: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 03:22:43 +03:00
|
|
|
add_to_unbuddied(pool, zhdr);
|
2016-05-21 02:58:30 +03: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-07 02:24:47 +03:00
|
|
|
spin_lock(&pool->lock);
|
2016-05-21 02:58:30 +03:00
|
|
|
/* Add/move z3fold page to beginning of LRU */
|
|
|
|
if (!list_empty(&page->lru))
|
|
|
|
list_del(&page->lru);
|
|
|
|
|
|
|
|
list_add(&page->lru, &pool->lru);
|
|
|
|
|
|
|
|
*handle = encode_handle(zhdr, bud);
|
|
|
|
spin_unlock(&pool->lock);
|
2017-02-25 01:57:23 +03:00
|
|
|
if (bud != HEADLESS)
|
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-21 02:58:30 +03: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
|
|
|
|
* reclaim, as indicated by the PG_reclaim flag being set, this function
|
|
|
|
* only sets the first|last_chunks to 0. The page is actually freed
|
|
|
|
* once both buddies are evicted (see z3fold_reclaim_page() below).
|
|
|
|
*/
|
|
|
|
static void z3fold_free(struct z3fold_pool *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr;
|
|
|
|
struct page *page;
|
|
|
|
enum buddy bud;
|
|
|
|
|
|
|
|
zhdr = handle_to_z3fold_header(handle);
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private)) {
|
2018-11-17 02:07:56 +03: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.
|
|
|
|
*/
|
|
|
|
if (!test_and_set_bit(PAGE_CLAIMED, &page->private)) {
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_del(&page->lru);
|
|
|
|
spin_unlock(&pool->lock);
|
2019-05-14 03:22:52 +03:00
|
|
|
free_z3fold_page(page, true);
|
2018-11-17 02:07:56 +03:00
|
|
|
atomic64_dec(&pool->pages_nr);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
2018-11-17 02:07:56 +03:00
|
|
|
return;
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
2018-11-17 02:07:56 +03:00
|
|
|
/* Non-headless case */
|
|
|
|
z3fold_page_lock(zhdr);
|
|
|
|
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);
|
|
|
|
z3fold_page_unlock(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-07 02:24:47 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-05-14 03:22:49 +03:00
|
|
|
free_handle(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-07 02:24:47 +03:00
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked_list)) {
|
|
|
|
atomic64_dec(&pool->pages_nr);
|
|
|
|
return;
|
|
|
|
}
|
2018-11-17 02:07:56 +03:00
|
|
|
if (test_bit(PAGE_CLAIMED, &page->private)) {
|
2018-05-12 02:01:46 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return;
|
|
|
|
}
|
2019-05-14 03:22:52 +03:00
|
|
|
if (unlikely(PageIsolated(page)) ||
|
|
|
|
test_and_set_bit(NEEDS_COMPACTING, &page->private)) {
|
2017-02-25 01:57:26 +03:00
|
|
|
z3fold_page_unlock(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-07 02:24:47 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (zhdr->cpu < 0 || !cpu_online(zhdr->cpu)) {
|
2017-02-25 01:57:23 +03: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-07 02:24:47 +03:00
|
|
|
list_del_init(&zhdr->buddy);
|
2017-02-25 01:57:23 +03: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-07 02:24:47 +03:00
|
|
|
zhdr->cpu = -1;
|
2017-11-18 02:26:16 +03:00
|
|
|
kref_get(&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-07 02:24:47 +03:00
|
|
|
do_compact_page(zhdr, true);
|
|
|
|
return;
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
2017-11-18 02:26:16 +03:00
|
|
|
kref_get(&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-07 02:24:47 +03:00
|
|
|
queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work);
|
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_reclaim_page() - evicts allocations from a pool page and frees it
|
|
|
|
* @pool: pool from which a page will attempt to be evicted
|
2018-02-07 02:42:16 +03:00
|
|
|
* @retries: number of pages on the LRU list for which eviction will
|
2016-05-21 02:58:30 +03:00
|
|
|
* be attempted before failing
|
|
|
|
*
|
|
|
|
* z3fold reclaim is different from normal system reclaim in that it is done
|
|
|
|
* from the bottom, up. This is because only the bottom layer, z3fold, has
|
|
|
|
* information on how the allocations are organized within each z3fold page.
|
|
|
|
* This has the potential to create interesting locking situations between
|
|
|
|
* z3fold and the user, however.
|
|
|
|
*
|
|
|
|
* To avoid these, this is how z3fold_reclaim_page() should be called:
|
2018-02-07 02:42:16 +03:00
|
|
|
*
|
2016-05-21 02:58:30 +03:00
|
|
|
* The user detects a page should be reclaimed and calls z3fold_reclaim_page().
|
|
|
|
* z3fold_reclaim_page() will remove a z3fold page from the pool LRU list and
|
|
|
|
* call the user-defined eviction handler with the pool and handle as
|
|
|
|
* arguments.
|
|
|
|
*
|
|
|
|
* If the handle can not be evicted, the eviction handler should return
|
|
|
|
* non-zero. z3fold_reclaim_page() will add the z3fold page back to the
|
|
|
|
* appropriate list and try the next z3fold page on the LRU up to
|
|
|
|
* a user defined number of retries.
|
|
|
|
*
|
|
|
|
* If the handle is successfully evicted, the eviction handler should
|
|
|
|
* return 0 _and_ should have called z3fold_free() on the handle. z3fold_free()
|
|
|
|
* contains logic to delay freeing the page if the page is under reclaim,
|
|
|
|
* as indicated by the setting of the PG_reclaim flag on the underlying page.
|
|
|
|
*
|
|
|
|
* If all buddies in the z3fold page are successfully evicted, then the
|
|
|
|
* z3fold page can be freed.
|
|
|
|
*
|
|
|
|
* Returns: 0 if page is successfully freed, otherwise -EINVAL if there are
|
|
|
|
* no pages to evict or an eviction handler is not registered, -EAGAIN if
|
|
|
|
* the retry limit was hit.
|
|
|
|
*/
|
|
|
|
static int z3fold_reclaim_page(struct z3fold_pool *pool, unsigned int retries)
|
|
|
|
{
|
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-07 02:24:47 +03:00
|
|
|
int i, ret = 0;
|
|
|
|
struct z3fold_header *zhdr = NULL;
|
|
|
|
struct page *page = NULL;
|
|
|
|
struct list_head *pos;
|
2016-05-21 02:58:30 +03:00
|
|
|
unsigned long first_handle = 0, middle_handle = 0, last_handle = 0;
|
|
|
|
|
|
|
|
spin_lock(&pool->lock);
|
2017-02-25 01:57:23 +03:00
|
|
|
if (!pool->ops || !pool->ops->evict || retries == 0) {
|
2016-05-21 02:58:30 +03:00
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
for (i = 0; i < retries; i++) {
|
2017-02-25 01:57:23 +03:00
|
|
|
if (list_empty(&pool->lru)) {
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
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-07 02:24:47 +03:00
|
|
|
list_for_each_prev(pos, &pool->lru) {
|
|
|
|
page = list_entry(pos, struct page, lru);
|
2018-11-17 02:07:56 +03:00
|
|
|
|
|
|
|
/* this bit could have been set by free, in which case
|
|
|
|
* we pass over to the next page in the pool.
|
|
|
|
*/
|
|
|
|
if (test_and_set_bit(PAGE_CLAIMED, &page->private))
|
|
|
|
continue;
|
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
if (unlikely(PageIsolated(page)))
|
|
|
|
continue;
|
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-07 02:24:47 +03:00
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
|
|
|
break;
|
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
zhdr = page_address(page);
|
2018-11-17 02:07:56 +03:00
|
|
|
if (!z3fold_page_trylock(zhdr)) {
|
|
|
|
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-07 02:24:47 +03:00
|
|
|
continue; /* can't evict at this point */
|
2018-11-17 02:07:56 +03: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-07 02:24:47 +03:00
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
zhdr->cpu = -1;
|
2018-05-12 02:01:46 +03:00
|
|
|
break;
|
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-07 02:24:47 +03:00
|
|
|
}
|
|
|
|
|
2018-11-17 02:07:56 +03:00
|
|
|
if (!zhdr)
|
|
|
|
break;
|
|
|
|
|
2017-02-25 01:57:26 +03:00
|
|
|
list_del_init(&page->lru);
|
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-07 02:24:47 +03:00
|
|
|
spin_unlock(&pool->lock);
|
2016-05-21 02:58:30 +03:00
|
|
|
|
|
|
|
if (!test_bit(PAGE_HEADLESS, &page->private)) {
|
|
|
|
/*
|
|
|
|
* We need encode the handles before unlocking, since
|
|
|
|
* we can race with free that will set
|
|
|
|
* (first|last)_chunks to 0
|
|
|
|
*/
|
|
|
|
first_handle = 0;
|
|
|
|
last_handle = 0;
|
|
|
|
middle_handle = 0;
|
|
|
|
if (zhdr->first_chunks)
|
|
|
|
first_handle = encode_handle(zhdr, FIRST);
|
|
|
|
if (zhdr->middle_chunks)
|
|
|
|
middle_handle = encode_handle(zhdr, MIDDLE);
|
|
|
|
if (zhdr->last_chunks)
|
|
|
|
last_handle = encode_handle(zhdr, LAST);
|
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-07 02:24:47 +03:00
|
|
|
/*
|
|
|
|
* it's safe to unlock here because we hold a
|
|
|
|
* reference to this page
|
|
|
|
*/
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
} else {
|
|
|
|
first_handle = encode_handle(zhdr, HEADLESS);
|
|
|
|
last_handle = middle_handle = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Issue the eviction callback(s) */
|
|
|
|
if (middle_handle) {
|
|
|
|
ret = pool->ops->evict(pool, middle_handle);
|
|
|
|
if (ret)
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
if (first_handle) {
|
|
|
|
ret = pool->ops->evict(pool, first_handle);
|
|
|
|
if (ret)
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
if (last_handle) {
|
|
|
|
ret = pool->ops->evict(pool, last_handle);
|
|
|
|
if (ret)
|
|
|
|
goto next;
|
|
|
|
}
|
|
|
|
next:
|
2017-02-25 01:57:26 +03:00
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private)) {
|
|
|
|
if (ret == 0) {
|
2019-05-14 03:22:52 +03:00
|
|
|
free_z3fold_page(page, true);
|
2018-11-17 02:07:56 +03:00
|
|
|
atomic64_dec(&pool->pages_nr);
|
2017-02-25 01:57:26 +03:00
|
|
|
return 0;
|
|
|
|
}
|
2018-05-12 02:01:46 +03:00
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&page->lru, &pool->lru);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
} else {
|
|
|
|
z3fold_page_lock(zhdr);
|
2018-11-17 02:07:56 +03:00
|
|
|
clear_bit(PAGE_CLAIMED, &page->private);
|
2018-05-12 02:01:46 +03:00
|
|
|
if (kref_put(&zhdr->refcount,
|
|
|
|
release_z3fold_page_locked)) {
|
|
|
|
atomic64_dec(&pool->pages_nr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* if we are here, the page is still not completely
|
|
|
|
* free. Take the global pool lock then to be able
|
|
|
|
* to add it back to the lru list
|
|
|
|
*/
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&page->lru, &pool->lru);
|
2017-10-04 02:14:47 +03:00
|
|
|
spin_unlock(&pool->lock);
|
2018-05-12 02:01:46 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
2017-02-25 01:57:26 +03:00
|
|
|
}
|
2017-02-25 01:57:23 +03:00
|
|
|
|
2018-05-12 02:01:46 +03:00
|
|
|
/* We started off locked to we need to lock the pool back */
|
|
|
|
spin_lock(&pool->lock);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
zhdr = handle_to_z3fold_header(handle);
|
|
|
|
addr = zhdr;
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
|
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
|
|
|
goto out;
|
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_lock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
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-17 02:07:56 +03:00
|
|
|
addr += PAGE_SIZE - (handle_to_chunks(handle) << CHUNK_SHIFT);
|
2016-05-21 02:58:30 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("unknown buddy id %d\n", buddy);
|
|
|
|
WARN_ON(1);
|
|
|
|
addr = NULL;
|
|
|
|
break;
|
|
|
|
}
|
2017-02-25 01:57:23 +03:00
|
|
|
|
2019-05-14 03:22:52 +03:00
|
|
|
if (addr)
|
|
|
|
zhdr->mapped_count++;
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
out:
|
|
|
|
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;
|
|
|
|
|
|
|
|
zhdr = handle_to_z3fold_header(handle);
|
|
|
|
page = virt_to_page(zhdr);
|
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
2016-05-21 02:58:30 +03:00
|
|
|
return;
|
|
|
|
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_lock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
buddy = handle_to_buddy(handle);
|
|
|
|
if (buddy == MIDDLE)
|
|
|
|
clear_bit(MIDDLE_CHUNK_MAPPED, &page->private);
|
2019-05-14 03:22:52 +03:00
|
|
|
zhdr->mapped_count--;
|
2017-02-25 01:57:23 +03:00
|
|
|
z3fold_page_unlock(zhdr);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* z3fold_get_pool_size() - gets the z3fold pool size in pages
|
|
|
|
* @pool: pool whose size is being queried
|
|
|
|
*
|
2017-02-25 01:57:15 +03:00
|
|
|
* Returns: size in pages of the given pool.
|
2016-05-21 02:58:30 +03:00
|
|
|
*/
|
|
|
|
static u64 z3fold_get_pool_size(struct z3fold_pool *pool)
|
|
|
|
{
|
2017-02-25 01:57:15 +03:00
|
|
|
return atomic64_read(&pool->pages_nr);
|
2016-05-21 02:58:30 +03:00
|
|
|
}
|
|
|
|
|
2019-05-14 03:22:52 +03: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(!PageMovable(page), page);
|
|
|
|
VM_BUG_ON_PAGE(PageIsolated(page), page);
|
|
|
|
|
|
|
|
if (test_bit(PAGE_HEADLESS, &page->private))
|
|
|
|
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;
|
|
|
|
|
|
|
|
pool = zhdr_to_pool(zhdr);
|
|
|
|
|
|
|
|
if (zhdr->mapped_count == 0) {
|
|
|
|
kref_get(&zhdr->refcount);
|
|
|
|
if (!list_empty(&zhdr->buddy))
|
|
|
|
list_del_init(&zhdr->buddy);
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
if (!list_empty(&page->lru))
|
|
|
|
list_del(&page->lru);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int z3fold_page_migrate(struct address_space *mapping, struct page *newpage,
|
|
|
|
struct page *page, enum migrate_mode mode)
|
|
|
|
{
|
|
|
|
struct z3fold_header *zhdr, *new_zhdr;
|
|
|
|
struct z3fold_pool *pool;
|
|
|
|
struct address_space *new_mapping;
|
|
|
|
|
|
|
|
VM_BUG_ON_PAGE(!PageMovable(page), page);
|
|
|
|
VM_BUG_ON_PAGE(!PageIsolated(page), page);
|
|
|
|
|
|
|
|
zhdr = page_address(page);
|
|
|
|
pool = zhdr_to_pool(zhdr);
|
|
|
|
|
|
|
|
if (!trylock_page(page))
|
|
|
|
return -EAGAIN;
|
|
|
|
|
|
|
|
if (!z3fold_page_trylock(zhdr)) {
|
|
|
|
unlock_page(page);
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
if (zhdr->mapped_count != 0) {
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
unlock_page(page);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
new_zhdr = page_address(newpage);
|
|
|
|
memcpy(new_zhdr, zhdr, PAGE_SIZE);
|
|
|
|
newpage->private = page->private;
|
|
|
|
page->private = 0;
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
spin_lock_init(&new_zhdr->page_lock);
|
|
|
|
new_mapping = page_mapping(page);
|
|
|
|
__ClearPageMovable(page);
|
|
|
|
ClearPagePrivate(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();
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&newpage->lru, &pool->lru);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
__SetPageMovable(newpage, new_mapping);
|
|
|
|
z3fold_page_unlock(new_zhdr);
|
|
|
|
|
|
|
|
queue_work_on(new_zhdr->cpu, pool->compact_wq, &new_zhdr->work);
|
|
|
|
|
|
|
|
page_mapcount_reset(page);
|
|
|
|
unlock_page(page);
|
|
|
|
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);
|
|
|
|
if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
|
|
|
|
atomic64_dec(&pool->pages_nr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
spin_lock(&pool->lock);
|
|
|
|
list_add(&page->lru, &pool->lru);
|
|
|
|
spin_unlock(&pool->lock);
|
|
|
|
z3fold_page_unlock(zhdr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct address_space_operations z3fold_aops = {
|
|
|
|
.isolate_page = z3fold_page_isolate,
|
|
|
|
.migratepage = z3fold_page_migrate,
|
|
|
|
.putback_page = z3fold_page_putback,
|
|
|
|
};
|
|
|
|
|
2016-05-21 02:58:30 +03:00
|
|
|
/*****************
|
|
|
|
* zpool
|
|
|
|
****************/
|
|
|
|
|
|
|
|
static int z3fold_zpool_evict(struct z3fold_pool *pool, unsigned long handle)
|
|
|
|
{
|
|
|
|
if (pool->zpool && pool->zpool_ops && pool->zpool_ops->evict)
|
|
|
|
return pool->zpool_ops->evict(pool->zpool, handle);
|
|
|
|
else
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct z3fold_ops z3fold_zpool_ops = {
|
|
|
|
.evict = z3fold_zpool_evict
|
|
|
|
};
|
|
|
|
|
|
|
|
static void *z3fold_zpool_create(const char *name, gfp_t gfp,
|
|
|
|
const struct zpool_ops *zpool_ops,
|
|
|
|
struct zpool *zpool)
|
|
|
|
{
|
|
|
|
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-07 02:24:47 +03:00
|
|
|
pool = z3fold_create_pool(name, gfp,
|
|
|
|
zpool_ops ? &z3fold_zpool_ops : NULL);
|
2016-05-21 02:58:30 +03:00
|
|
|
if (pool) {
|
|
|
|
pool->zpool = zpool;
|
|
|
|
pool->zpool_ops = zpool_ops;
|
|
|
|
}
|
|
|
|
return pool;
|
|
|
|
}
|
|
|
|
|
|
|
|
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 int z3fold_zpool_shrink(void *pool, unsigned int pages,
|
|
|
|
unsigned int *reclaimed)
|
|
|
|
{
|
|
|
|
unsigned int total = 0;
|
|
|
|
int ret = -EINVAL;
|
|
|
|
|
|
|
|
while (total < pages) {
|
|
|
|
ret = z3fold_reclaim_page(pool, 8);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
total++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (reclaimed)
|
|
|
|
*reclaimed = total;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
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",
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.create = z3fold_zpool_create,
|
|
|
|
.destroy = z3fold_zpool_destroy,
|
|
|
|
.malloc = z3fold_zpool_malloc,
|
|
|
|
.free = z3fold_zpool_free,
|
|
|
|
.shrink = z3fold_zpool_shrink,
|
|
|
|
.map = z3fold_zpool_map,
|
|
|
|
.unmap = z3fold_zpool_unmap,
|
|
|
|
.total_size = z3fold_zpool_total_size,
|
|
|
|
};
|
|
|
|
|
|
|
|
MODULE_ALIAS("zpool-z3fold");
|
|
|
|
|
|
|
|
static int __init init_z3fold(void)
|
|
|
|
{
|
2019-05-14 03:22:52 +03:00
|
|
|
int ret;
|
|
|
|
|
2017-02-25 01:57:17 +03:00
|
|
|
/* Make sure the z3fold header is not larger than the page size */
|
|
|
|
BUILD_BUG_ON(ZHDR_SIZE_ALIGNED > PAGE_SIZE);
|
2019-05-14 03:22:52 +03:00
|
|
|
ret = z3fold_mount();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-05-21 02:58:30 +03:00
|
|
|
zpool_register_driver(&z3fold_zpool_driver);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit exit_z3fold(void)
|
|
|
|
{
|
2019-05-14 03:22:52 +03:00
|
|
|
z3fold_unmount();
|
2016-05-21 02:58:30 +03:00
|
|
|
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");
|