2019-05-19 15:08:20 +03:00
// SPDX-License-Identifier: GPL-2.0-only
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>
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>
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>
2020-05-28 08:20:40 +03:00
# include <linux/kmemleak.h>
2016-05-21 02:58:30 +03:00
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)
2021-07-01 04:50:24 +03:00
# define NCHUNKS (TOTAL_CHUNKS - ZHDR_CHUNKS)
2019-05-14 03:22:49 +03:00
# 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 ] ;
2020-12-15 06:12:30 +03:00
unsigned long pool ; /* back link */
2019-12-01 04:56:11 +03:00
rwlock_t lock ;
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
2019-07-17 02:25:48 +03:00
* @ pool : pointer to the containing pool
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-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 ;
2019-07-17 02:25:48 +03:00
struct z3fold_pool * pool ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-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 ;
2019-12-01 04:56:11 +03:00
unsigned short foreign_handles : 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 .
2021-07-01 04:53:44 +03:00
* @ zpool : zpool driver
* @ zpool_ops : zpool operations structure with an evict callback
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-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
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 ;
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 */
2022-04-29 09:40:43 +03:00
PAGE_MIGRATED , /* page is migrated and soon to be released */
2016-05-21 02:58:30 +03:00
} ;
2020-12-15 06:12:33 +03:00
/*
* handle flags , go under HANDLE_FLAG_MASK
*/
enum z3fold_handle_flags {
HANDLES_NOFREE = 0 ,
} ;
2019-12-01 04:56:11 +03:00
/*
* Forward declarations
*/
static struct z3fold_header * __z3fold_alloc ( struct z3fold_pool * , size_t , bool ) ;
static void compact_page_work ( struct work_struct * w ) ;
2016-05-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 ) + + )
2019-06-01 08:30:39 +03:00
static inline struct z3fold_buddy_slots * alloc_slots ( struct z3fold_pool * pool ,
gfp_t gfp )
2019-05-14 03:22:49 +03:00
{
2022-04-29 09:40:43 +03:00
struct z3fold_buddy_slots * slots = kmem_cache_zalloc ( pool - > c_handle ,
gfp ) ;
2019-05-14 03:22:49 +03:00
if ( slots ) {
2020-05-28 08:20:40 +03:00
/* It will be freed separately in free_handle(). */
kmemleak_not_leak ( slots ) ;
2019-05-14 03:22:49 +03:00
slots - > pool = ( unsigned long ) pool ;
2019-12-01 04:56:11 +03:00
rwlock_init ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
}
return slots ;
}
static inline struct z3fold_pool * slots_to_pool ( struct z3fold_buddy_slots * s )
{
return ( struct z3fold_pool * ) ( s - > pool & ~ HANDLE_FLAG_MASK ) ;
}
static inline struct z3fold_buddy_slots * handle_to_slots ( unsigned long handle )
{
return ( struct z3fold_buddy_slots * ) ( handle & ~ ( SLOTS_ALIGN - 1 ) ) ;
}
2019-12-01 04:56:11 +03:00
/* Lock a z3fold page */
static inline void z3fold_page_lock ( struct z3fold_header * zhdr )
{
spin_lock ( & zhdr - > page_lock ) ;
}
/* Try to lock a z3fold page */
static inline int z3fold_page_trylock ( struct z3fold_header * zhdr )
{
return spin_trylock ( & zhdr - > page_lock ) ;
}
/* Unlock a z3fold page */
static inline void z3fold_page_unlock ( struct z3fold_header * zhdr )
{
spin_unlock ( & zhdr - > page_lock ) ;
}
2021-07-01 04:50:33 +03:00
/* return locked z3fold page if it's not headless */
static inline struct z3fold_header * get_z3fold_header ( unsigned long handle )
2019-12-01 04:56:11 +03:00
{
struct z3fold_buddy_slots * slots ;
struct z3fold_header * zhdr ;
int locked = 0 ;
if ( ! ( handle & ( 1 < < PAGE_HEADLESS ) ) ) {
slots = handle_to_slots ( handle ) ;
do {
unsigned long addr ;
read_lock ( & slots - > lock ) ;
addr = * ( unsigned long * ) handle ;
zhdr = ( struct z3fold_header * ) ( addr & PAGE_MASK ) ;
2021-07-01 04:50:33 +03:00
locked = z3fold_page_trylock ( zhdr ) ;
2019-12-01 04:56:11 +03:00
read_unlock ( & slots - > lock ) ;
2022-04-29 09:40:43 +03:00
if ( locked ) {
struct page * page = virt_to_page ( zhdr ) ;
if ( ! test_bit ( PAGE_MIGRATED , & page - > private ) )
break ;
z3fold_page_unlock ( zhdr ) ;
}
2019-12-01 04:56:11 +03:00
cpu_relax ( ) ;
2021-07-01 04:50:33 +03:00
} while ( true ) ;
2019-12-01 04:56:11 +03:00
} else {
zhdr = ( struct z3fold_header * ) ( handle & PAGE_MASK ) ;
}
return zhdr ;
}
static inline void put_z3fold_header ( struct z3fold_header * zhdr )
{
struct page * page = virt_to_page ( zhdr ) ;
if ( ! test_bit ( PAGE_HEADLESS , & page - > private ) )
z3fold_page_unlock ( zhdr ) ;
}
2020-12-15 06:12:30 +03:00
static inline void free_handle ( unsigned long handle , struct z3fold_header * zhdr )
2019-05-14 03:22:49 +03:00
{
struct z3fold_buddy_slots * slots ;
int i ;
bool is_free ;
2019-12-01 04:56:11 +03:00
if ( WARN_ON ( * ( unsigned long * ) handle = = 0 ) )
return ;
2019-05-14 03:22:49 +03:00
slots = handle_to_slots ( handle ) ;
2019-12-01 04:56:11 +03:00
write_lock ( & slots - > lock ) ;
* ( unsigned long * ) handle = 0 ;
2020-12-15 06:12:33 +03:00
if ( test_bit ( HANDLES_NOFREE , & slots - > pool ) ) {
write_unlock ( & slots - > lock ) ;
return ; /* simple case, nothing else to do */
}
2020-12-15 06:12:30 +03:00
if ( zhdr - > slots ! = slots )
zhdr - > foreign_handles - - ;
2019-12-01 04:56:11 +03:00
2019-05-14 03:22:49 +03:00
is_free = true ;
for ( i = 0 ; i < = BUDDY_MASK ; i + + ) {
if ( slots - > slot [ i ] ) {
is_free = false ;
break ;
}
}
2020-05-23 08:23:12 +03:00
write_unlock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
if ( is_free ) {
struct z3fold_pool * pool = slots_to_pool ( slots ) ;
2020-12-15 06:12:30 +03:00
if ( zhdr - > slots = = slots )
zhdr - > slots = NULL ;
2019-05-14 03:22:49 +03:00
kmem_cache_free ( pool - > c_handle , slots ) ;
}
}
2016-05-21 02:58:30 +03:00
/* Initializes the z3fold header of a newly allocated z3fold page */
2019-09-24 01:36:51 +03:00
static struct z3fold_header * init_z3fold_page ( struct page * page , bool headless ,
2019-06-01 08:30:39 +03:00
struct z3fold_pool * pool , gfp_t gfp )
2016-05-21 02:58:30 +03:00
{
struct z3fold_header * zhdr = page_address ( page ) ;
2019-09-24 01:36:51 +03:00
struct z3fold_buddy_slots * slots ;
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 ) ;
2022-04-29 09:40:43 +03:00
clear_bit ( PAGE_MIGRATED , & page - > private ) ;
2019-09-24 01:36:51 +03:00
if ( headless )
return zhdr ;
slots = alloc_slots ( pool , gfp ) ;
if ( ! slots )
return NULL ;
2016-05-21 02:58:30 +03:00
2021-02-24 23:09:22 +03:00
memset ( zhdr , 0 , sizeof ( * zhdr ) ) ;
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 ) ;
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 ;
2019-07-17 02:25:48 +03:00
zhdr - > pool = pool ;
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 ) ;
}
2017-02-25 01:57:26 +03:00
__free_page ( page ) ;
}
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
*/
2019-09-24 01:33:02 +03:00
static unsigned long __encode_handle ( struct z3fold_header * zhdr ,
struct z3fold_buddy_slots * slots ,
enum buddy bud )
2016-05-21 02:58:30 +03:00
{
2019-05-14 03:22:49 +03:00
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 ) ;
2019-12-01 04:56:11 +03:00
write_lock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
slots - > slot [ idx ] = h ;
2019-12-01 04:56:11 +03:00
write_unlock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
return ( unsigned long ) & slots - > slot [ idx ] ;
2016-05-21 02:58:30 +03:00
}
2019-09-24 01:33:02 +03:00
static unsigned long encode_handle ( struct z3fold_header * zhdr , enum buddy bud )
{
return __encode_handle ( zhdr , zhdr - > slots , bud ) ;
}
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-12-01 04:56:11 +03:00
struct z3fold_buddy_slots * slots = handle_to_slots ( handle ) ;
unsigned long addr ;
2019-05-14 03:22:49 +03:00
2019-12-01 04:56:11 +03:00
read_lock ( & slots - > lock ) ;
addr = * ( unsigned long * ) handle ;
read_unlock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
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 ;
2019-12-01 04:56:11 +03:00
struct z3fold_buddy_slots * slots = handle_to_slots ( handle ) ;
2019-05-14 03:22:49 +03:00
unsigned long addr ;
2019-12-01 04:56:11 +03:00
read_lock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
WARN_ON ( handle & ( 1 < < PAGE_HEADLESS ) ) ;
addr = * ( unsigned long * ) handle ;
2019-12-01 04:56:11 +03:00
read_unlock ( & slots - > lock ) ;
2019-05-14 03:22:49 +03:00
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-07-17 02:25:48 +03:00
return zhdr - > pool ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 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 ) ;
2019-12-01 04:56:11 +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
if ( locked )
z3fold_page_unlock ( zhdr ) ;
2019-12-01 04:56:11 +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
spin_lock ( & pool - > stale_lock ) ;
list_add ( & zhdr - > buddy , & pool - > stale ) ;
queue_work ( pool - > release_wq , & pool - > work ) ;
spin_unlock ( & pool - > stale_lock ) ;
2022-04-29 09:16:05 +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
}
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 ) ;
2019-12-01 04:56:11 +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
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 ) {
2020-12-15 06:12:36 +03:00
struct list_head * unbuddied ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
int freechunks = num_free_chunks ( zhdr ) ;
2020-12-15 06:12:36 +03:00
migrate_disable ( ) ;
unbuddied = this_cpu_ptr ( pool - > unbuddied ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
spin_lock ( & pool - > lock ) ;
list_add ( & zhdr - > buddy , & unbuddied [ freechunks ] ) ;
spin_unlock ( & pool - > lock ) ;
zhdr - > cpu = smp_processor_id ( ) ;
2020-12-15 06:12:36 +03:00
migrate_enable ( ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
}
}
2020-12-15 06:12:33 +03:00
static inline enum buddy get_free_buddy ( struct z3fold_header * zhdr , int chunks )
{
enum buddy bud = HEADLESS ;
if ( zhdr - > middle_chunks ) {
if ( ! zhdr - > first_chunks & &
chunks < = zhdr - > start_middle - ZHDR_CHUNKS )
bud = FIRST ;
else if ( ! zhdr - > last_chunks )
bud = LAST ;
} else {
if ( ! zhdr - > first_chunks )
bud = FIRST ;
else if ( ! zhdr - > last_chunks )
bud = LAST ;
else
bud = MIDDLE ;
}
return bud ;
}
2017-02-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 ) ;
}
2019-12-01 04:56:11 +03:00
static inline bool buddy_single ( struct z3fold_header * zhdr )
{
return ! ( ( zhdr - > first_chunks & & zhdr - > middle_chunks ) | |
( zhdr - > first_chunks & & zhdr - > last_chunks ) | |
( zhdr - > middle_chunks & & zhdr - > last_chunks ) ) ;
}
static struct z3fold_header * compact_single_buddy ( struct z3fold_header * zhdr )
{
struct z3fold_pool * pool = zhdr_to_pool ( zhdr ) ;
void * p = zhdr ;
unsigned long old_handle = 0 ;
size_t sz = 0 ;
struct z3fold_header * new_zhdr = NULL ;
int first_idx = __idx ( zhdr , FIRST ) ;
int middle_idx = __idx ( zhdr , MIDDLE ) ;
int last_idx = __idx ( zhdr , LAST ) ;
unsigned short * moved_chunks = NULL ;
/*
* No need to protect slots here - - all the slots are " local " and
* the page lock is already taken
*/
if ( zhdr - > first_chunks & & zhdr - > slots - > slot [ first_idx ] ) {
p + = ZHDR_SIZE_ALIGNED ;
sz = zhdr - > first_chunks < < CHUNK_SHIFT ;
old_handle = ( unsigned long ) & zhdr - > slots - > slot [ first_idx ] ;
moved_chunks = & zhdr - > first_chunks ;
} else if ( zhdr - > middle_chunks & & zhdr - > slots - > slot [ middle_idx ] ) {
p + = zhdr - > start_middle < < CHUNK_SHIFT ;
sz = zhdr - > middle_chunks < < CHUNK_SHIFT ;
old_handle = ( unsigned long ) & zhdr - > slots - > slot [ middle_idx ] ;
moved_chunks = & zhdr - > middle_chunks ;
} else if ( zhdr - > last_chunks & & zhdr - > slots - > slot [ last_idx ] ) {
p + = PAGE_SIZE - ( zhdr - > last_chunks < < CHUNK_SHIFT ) ;
sz = zhdr - > last_chunks < < CHUNK_SHIFT ;
old_handle = ( unsigned long ) & zhdr - > slots - > slot [ last_idx ] ;
moved_chunks = & zhdr - > last_chunks ;
}
if ( sz > 0 ) {
enum buddy new_bud = HEADLESS ;
short chunks = size_to_chunks ( sz ) ;
void * q ;
new_zhdr = __z3fold_alloc ( pool , sz , false ) ;
if ( ! new_zhdr )
return NULL ;
if ( WARN_ON ( new_zhdr = = zhdr ) )
goto out_fail ;
2020-12-15 06:12:33 +03:00
new_bud = get_free_buddy ( new_zhdr , chunks ) ;
2019-12-01 04:56:11 +03:00
q = new_zhdr ;
switch ( new_bud ) {
case FIRST :
new_zhdr - > first_chunks = chunks ;
q + = ZHDR_SIZE_ALIGNED ;
break ;
case MIDDLE :
new_zhdr - > middle_chunks = chunks ;
new_zhdr - > start_middle =
new_zhdr - > first_chunks + ZHDR_CHUNKS ;
q + = new_zhdr - > start_middle < < CHUNK_SHIFT ;
break ;
case LAST :
new_zhdr - > last_chunks = chunks ;
q + = PAGE_SIZE - ( new_zhdr - > last_chunks < < CHUNK_SHIFT ) ;
break ;
default :
goto out_fail ;
}
new_zhdr - > foreign_handles + + ;
memcpy ( q , p , sz ) ;
write_lock ( & zhdr - > slots - > lock ) ;
* ( unsigned long * ) old_handle = ( unsigned long ) new_zhdr +
__idx ( new_zhdr , new_bud ) ;
if ( new_bud = = LAST )
* ( unsigned long * ) old_handle | =
( new_zhdr - > last_chunks < < BUDDY_SHIFT ) ;
write_unlock ( & zhdr - > slots - > lock ) ;
add_to_unbuddied ( pool , new_zhdr ) ;
z3fold_page_unlock ( new_zhdr ) ;
* moved_chunks = 0 ;
}
return new_zhdr ;
out_fail :
2022-04-29 09:16:05 +03:00
if ( new_zhdr & & ! kref_put ( & new_zhdr - > refcount , release_z3fold_page_locked ) ) {
add_to_unbuddied ( pool , new_zhdr ) ;
z3fold_page_unlock ( new_zhdr ) ;
2019-12-01 04:56:11 +03:00
}
return NULL ;
}
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 ) ;
2022-04-29 09:16:05 +03:00
if ( kref_put ( & zhdr - > refcount , release_z3fold_page_locked ) )
2017-11-18 02:26:16 +03:00
return ;
2020-12-15 06:12:33 +03:00
if ( test_bit ( PAGE_STALE , & page - > private ) | |
test_and_set_bit ( PAGE_CLAIMED , & page - > private ) ) {
2019-05-14 03:22:52 +03:00
z3fold_page_unlock ( zhdr ) ;
return ;
}
2019-12-01 04:56:11 +03:00
if ( ! zhdr - > foreign_handles & & buddy_single ( zhdr ) & &
zhdr - > mapped_count = = 0 & & compact_single_buddy ( zhdr ) ) {
2022-04-29 09:16:05 +03:00
if ( ! kref_put ( & zhdr - > refcount , release_z3fold_page_locked ) ) {
2020-12-15 06:12:33 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2019-12-01 04:56:11 +03:00
z3fold_page_unlock ( zhdr ) ;
2020-12-15 06:12:33 +03:00
}
2019-12-01 04:56:11 +03:00
return ;
}
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-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 ) ;
2020-12-15 06:12:33 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-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 :
2020-12-15 06:12:36 +03:00
migrate_disable ( ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
/* First, try to find an unbuddied z3fold page. */
2020-12-15 06:12:36 +03:00
unbuddied = this_cpu_ptr ( pool - > unbuddied ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
for_each_unbuddied_list ( i , chunks ) {
struct list_head * l = & unbuddied [ i ] ;
zhdr = list_first_entry_or_null ( READ_ONCE ( l ) ,
struct z3fold_header , buddy ) ;
if ( ! zhdr )
continue ;
/* Re-check under lock. */
spin_lock ( & pool - > lock ) ;
if ( unlikely ( zhdr ! = list_first_entry ( READ_ONCE ( l ) ,
struct z3fold_header , buddy ) ) | |
! z3fold_page_trylock ( zhdr ) ) {
spin_unlock ( & pool - > lock ) ;
zhdr = NULL ;
2020-12-15 06:12:36 +03:00
migrate_enable ( ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
if ( can_sleep )
cond_resched ( ) ;
goto lookup ;
}
list_del_init ( & zhdr - > buddy ) ;
zhdr - > cpu = - 1 ;
spin_unlock ( & pool - > lock ) ;
page = virt_to_page ( zhdr ) ;
2019-12-01 04:56:11 +03:00
if ( test_bit ( NEEDS_COMPACTING , & page - > private ) | |
test_bit ( PAGE_CLAIMED , & page - > private ) ) {
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
z3fold_page_unlock ( zhdr ) ;
zhdr = NULL ;
2020-12-15 06:12:36 +03:00
migrate_enable ( ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
if ( can_sleep )
cond_resched ( ) ;
goto lookup ;
}
/*
* this page could not be removed from its unbuddied
* list while pool lock was held , and then we ' ve taken
* page lock so kref_put could not be called before
* we got here , so it ' s safe to just call kref_get ( )
*/
kref_get ( & zhdr - > refcount ) ;
break ;
}
2020-12-15 06:12:36 +03:00
migrate_enable ( ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
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 ) ;
2019-12-01 04:56:11 +03:00
if ( test_bit ( NEEDS_COMPACTING , & page - > private ) | |
test_bit ( PAGE_CLAIMED , & page - > private ) ) {
2019-05-14 03:22:46 +03:00
z3fold_page_unlock ( zhdr ) ;
zhdr = NULL ;
if ( can_sleep )
cond_resched ( ) ;
continue ;
}
kref_get ( & zhdr - > refcount ) ;
break ;
}
}
2022-04-29 09:40:43 +03:00
if ( zhdr & & ! zhdr - > slots ) {
2022-04-29 09:40:43 +03:00
zhdr - > slots = alloc_slots ( pool , GFP_ATOMIC ) ;
2022-04-29 09:40:43 +03:00
if ( ! zhdr - > slots )
goto out_fail ;
}
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 03:22:43 +03:00
return zhdr ;
2022-04-29 09:40:43 +03:00
out_fail :
if ( ! kref_put ( & zhdr - > refcount , release_z3fold_page_locked ) ) {
add_to_unbuddied ( pool , zhdr ) ;
z3fold_page_unlock ( zhdr ) ;
}
return NULL ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 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
/*
* 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 ) ;
2021-07-01 04:50:30 +03:00
pool - > unbuddied = __alloc_percpu ( sizeof ( struct list_head ) * NCHUNKS ,
__alignof__ ( struct list_head ) ) ;
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 ;
INIT_WORK ( & pool - > work , free_pages_work ) ;
pool - > ops = ops ;
return pool ;
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-08-14 01:37:21 +03:00
/*
* We need to destroy pool - > compact_wq before pool - > release_wq ,
* as any pending work on pool - > compact_wq will call
* queue_work ( pool - > release_wq , & pool - > work ) .
2019-08-14 01:37:25 +03:00
*
* There are still outstanding pages until both workqueues are drained ,
* so we cannot unregister migration until then .
2019-08-14 01:37:21 +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
destroy_workqueue ( pool - > compact_wq ) ;
2019-08-14 01:37:21 +03:00
destroy_workqueue ( pool - > release_wq ) ;
2021-07-01 04:50:36 +03:00
free_percpu ( pool - > unbuddied ) ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 02:24:47 +03:00
kfree ( pool ) ;
}
2022-06-07 22:38:48 +03:00
static const struct movable_operations z3fold_mops ;
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 .
*
* 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
2022-04-29 09:40:43 +03:00
if ( ! size | | ( gfp & __GFP_HIGHMEM ) )
2016-05-21 02:58:30 +03:00
return - EINVAL ;
if ( size > PAGE_SIZE )
return - ENOSPC ;
if ( size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE )
bud = HEADLESS ;
else {
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 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 ) {
2020-12-15 06:12:33 +03:00
bud = get_free_buddy ( zhdr , chunks ) ;
if ( bud = = HEADLESS ) {
2022-04-29 09:16:05 +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 ) )
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 ;
}
2022-04-29 09:40:43 +03:00
page = alloc_page ( gfp ) ;
2016-05-21 02:58:30 +03:00
if ( ! page )
return - ENOMEM ;
2017-02-25 01:57:23 +03:00
2019-09-24 01:36:51 +03:00
zhdr = init_z3fold_page ( page , bud = = HEADLESS , pool , gfp ) ;
mm/z3fold.c: introduce helper functions
Patch series "z3fold: support page migration", v2.
This patchset implements page migration support and slightly better buddy
search. To implement page migration support, z3fold has to move away from
the current scheme of handle encoding. i. e. stop encoding page address
in handles. Instead, a small per-page structure is created which will
contain actual addresses for z3fold objects, while pointers to fields of
that structure will be used as handles.
Thus, it will be possible to change the underlying addresses to reflect
page migration.
To support migration itself, 3 callbacks will be implemented:
1: isolation callback: z3fold_page_isolate(): try to isolate the page
by removing it from all lists. Pages scheduled for some activity and
mapped pages will not be isolated. Return true if isolation was
successful or false otherwise
2: migration callback: z3fold_page_migrate(): re-check critical
conditions and migrate page contents to the new page provided by the
system. Returns 0 on success or negative error code otherwise
3: putback callback: z3fold_page_putback(): put back the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
To make sure an isolated page doesn't get freed, its kref is incremented
in z3fold_page_isolate() and decremented during post-migration compaction,
if migration was successful, or by z3fold_page_putback() in the other
case.
Since the new handle encoding scheme implies slight memory consumption
increase, better buddy search (which decreases memory consumption) is
included in this patchset.
This patch (of 4):
Introduce a separate helper function for object allocation, as well as 2
smaller helpers to add a buddy to the list and to get a pointer to the
pool from the z3fold header. No functional changes here.
Link: http://lkml.kernel.org/r/20190417103633.a4bb770b5bf0fb7e43ce1666@gmail.com
Signed-off-by: Vitaly Wool <vitaly.vul@sony.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 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-07-12 06:52:14 +03:00
if ( can_sleep ) {
lock_page ( page ) ;
2022-06-07 22:38:48 +03:00
__SetPageMovable ( page , & z3fold_mops ) ;
2019-07-12 06:52:14 +03:00
unlock_page ( page ) ;
} else {
2022-04-29 09:40:43 +03:00
WARN_ON ( ! trylock_page ( page ) ) ;
2022-06-07 22:38:48 +03:00
__SetPageMovable ( page , & z3fold_mops ) ;
2022-04-29 09:40:43 +03:00
unlock_page ( page ) ;
2019-07-12 06:52:14 +03:00
}
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
2022-04-29 09:16:05 +03:00
* reclaim , as indicated by the PAGE_CLAIMED flag being set , this function
* only sets the first | middle | last_chunks to 0. The page is actually freed
* once all buddies are evicted ( see z3fold_reclaim_page ( ) below ) .
2016-05-21 02:58:30 +03:00
*/
static void z3fold_free ( struct z3fold_pool * pool , unsigned long handle )
{
struct z3fold_header * zhdr ;
struct page * page ;
enum buddy bud ;
2019-10-07 03:58:22 +03:00
bool page_claimed ;
2016-05-21 02:58:30 +03:00
2019-12-01 04:56:11 +03:00
zhdr = get_z3fold_header ( handle ) ;
2016-05-21 02:58:30 +03:00
page = virt_to_page ( zhdr ) ;
2019-10-07 03:58:22 +03:00
page_claimed = test_and_set_bit ( PAGE_CLAIMED , & page - > private ) ;
2016-05-21 02:58:30 +03:00
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 .
*/
2019-10-07 03:58:22 +03:00
if ( ! page_claimed ) {
2018-11-17 02:07:56 +03:00
spin_lock ( & pool - > lock ) ;
list_del ( & page - > lru ) ;
spin_unlock ( & pool - > lock ) ;
2019-12-01 04:56:11 +03:00
put_z3fold_header ( zhdr ) ;
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 */
bud = handle_to_buddy ( handle ) ;
switch ( bud ) {
case FIRST :
zhdr - > first_chunks = 0 ;
break ;
case MIDDLE :
zhdr - > middle_chunks = 0 ;
break ;
case LAST :
zhdr - > last_chunks = 0 ;
break ;
default :
pr_err ( " %s: unknown bud %d \n " , __func__ , bud ) ;
WARN_ON ( 1 ) ;
2019-12-01 04:56:11 +03:00
put_z3fold_header ( zhdr ) ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 02:24:47 +03:00
return ;
}
2019-12-01 04:56:11 +03:00
if ( ! page_claimed )
2020-12-15 06:12:30 +03:00
free_handle ( handle , zhdr ) ;
2022-04-29 09:16:05 +03:00
if ( kref_put ( & zhdr - > refcount , release_z3fold_page_locked_list ) )
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 02:24:47 +03:00
return ;
2019-10-07 03:58:22 +03:00
if ( page_claimed ) {
/* the page has not been claimed by us */
2022-04-29 09:16:05 +03:00
put_z3fold_header ( zhdr ) ;
2018-05-12 02:01:46 +03:00
return ;
}
2020-12-15 06:12:33 +03:00
if ( test_and_set_bit ( NEEDS_COMPACTING , & page - > private ) ) {
2019-10-07 03:58:22 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2022-04-29 09:40:43 +03:00
put_z3fold_header ( zhdr ) ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 02:24:47 +03:00
return ;
}
if ( zhdr - > cpu < 0 | | ! cpu_online ( zhdr - > cpu ) ) {
zhdr - > cpu = - 1 ;
2017-11-18 02:26:16 +03:00
kref_get ( & zhdr - > refcount ) ;
2019-10-07 03:58:22 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2019-12-01 04:56:11 +03:00
do_compact_page ( zhdr , true ) ;
z3fold: use per-cpu unbuddied lists
It's been noted that z3fold doesn't scale well when it's run in a large
number of threads on many cores, which can be easily reproduced with fio
'randrw' test with --numjobs=32. E.g. the result for 1 cluster (4 cores)
is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=496883KB/s, minb=15527KB/s, ...
WRITE: io=246735MB, aggrb=500841KB/s, minb=15651KB/s, ...
While for 8 cores (2 clusters) the result is:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=265942KB/s, minb=8310KB/s, ...
WRITE: io=246735MB, aggrb=268060KB/s, minb=8376KB/s, ...
The bottleneck here is the pool lock which many threads become waiting
upon. To reduce that spin lock contention, z3fold can operate only on
the lists local to the current CPU whenever possible. Due to the nature
of z3fold unbuddied list handling (it only takes the first entry off the
list on a hot path), if the z3fold pool is big enough and balanced well
enough, limiting search to only local unbuddied list doesn't lead to a
significant compression ratio degrade (2.57x vs 2.65x in our
measurements).
This patch also introduces two worker threads: one for async in-page
object layout optimization and one for releasing freed pages. This is
done to speed up z3fold_free() which is often on a hot path.
The fio results for 8-core case are now the following:
Run status group 0 (all jobs):
READ: io=244785MB, aggrb=1568.3MB/s, minb=50182KB/s, ...
WRITE: io=246735MB, aggrb=1580.8MB/s, minb=50582KB/s, ...
So we're in for almost 6x performance increase.
Link: http://lkml.kernel.org/r/20170806181443.f9b65018f8bde25ef990f9e8@gmail.com
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 02:24:47 +03:00
return ;
2016-05-21 02:58:30 +03:00
}
2017-11-18 02:26:16 +03:00
kref_get ( & zhdr - > refcount ) ;
2019-10-07 03:58:22 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2019-12-01 04:56:11 +03:00
queue_work_on ( zhdr - > cpu , pool - > compact_wq , & zhdr - > work ) ;
put_z3fold_header ( 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 )
{
2019-12-01 04:56:11 +03:00
int i , ret = - 1 ;
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 * 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 ;
2020-12-15 06:12:33 +03:00
struct z3fold_buddy_slots slots __attribute__ ( ( aligned ( SLOTS_ALIGN ) ) ) ;
rwlock_init ( & slots . lock ) ;
slots . pool = ( unsigned long ) pool | ( 1 < < HANDLES_NOFREE ) ;
2016-05-21 02:58:30 +03:00
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
2019-09-24 01:33:02 +03:00
zhdr = page_address ( page ) ;
2021-03-25 07:37:29 +03:00
if ( test_bit ( PAGE_HEADLESS , & page - > private ) ) {
/*
* For non - headless pages , we wait to do this
* until we have the page lock to avoid racing
* with __z3fold_alloc ( ) . Headless pages don ' t
* have a lock ( and __z3fold_alloc ( ) will never
* see them ) , but we still need to test and set
* PAGE_CLAIMED to avoid racing with
* z3fold_free ( ) , so just do it now before
* leaving the loop .
*/
if ( test_and_set_bit ( PAGE_CLAIMED , & page - > private ) )
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
break ;
2021-03-25 07:37:29 +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
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
}
2020-12-15 06:12:33 +03:00
/* test_and_set_bit is of course atomic, but we still
* need to do it under page lock , otherwise checking
* that bit in __z3fold_alloc wouldn ' t make sense
*/
if ( zhdr - > foreign_handles | |
test_and_set_bit ( PAGE_CLAIMED , & page - > private ) ) {
2022-04-29 09:40:43 +03:00
z3fold_page_unlock ( zhdr ) ;
2019-12-01 04:56:11 +03:00
zhdr = NULL ;
continue ; /* can't evict such 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
list_del_init ( & zhdr - > buddy ) ;
zhdr - > cpu = - 1 ;
2022-04-29 09:40:43 +03:00
/* See comment in __z3fold_alloc. */
kref_get ( & zhdr - > refcount ) ;
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 ) ) {
/*
2019-09-24 01:33:02 +03:00
* We need encode the handles before unlocking , and
* use our local slots structure because z3fold_free
* can zero out zhdr - > slots and we can ' t do much
* about that
2016-05-21 02:58:30 +03:00
*/
first_handle = 0 ;
last_handle = 0 ;
middle_handle = 0 ;
2020-12-15 06:12:33 +03:00
memset ( slots . slot , 0 , sizeof ( slots . slot ) ) ;
2016-05-21 02:58:30 +03:00
if ( zhdr - > first_chunks )
2020-12-15 06:12:33 +03:00
first_handle = __encode_handle ( zhdr , & slots ,
FIRST ) ;
2016-05-21 02:58:30 +03:00
if ( zhdr - > middle_chunks )
2020-12-15 06:12:33 +03:00
middle_handle = __encode_handle ( zhdr , & slots ,
MIDDLE ) ;
2016-05-21 02:58:30 +03:00
if ( zhdr - > last_chunks )
2020-12-15 06:12:33 +03:00
last_handle = __encode_handle ( zhdr , & slots ,
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 {
2019-12-01 04:56:11 +03:00
first_handle = encode_handle ( zhdr , HEADLESS ) ;
2016-05-21 02:58:30 +03:00
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 ) ;
2019-09-24 01:33:02 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2018-05-12 02:01:46 +03:00
} else {
2020-12-15 06:12:33 +03:00
struct z3fold_buddy_slots * slots = zhdr - > slots ;
2018-05-12 02:01:46 +03:00
z3fold_page_lock ( zhdr ) ;
if ( kref_put ( & zhdr - > refcount ,
release_z3fold_page_locked ) ) {
2020-12-15 06:12:33 +03:00
kmem_cache_free ( pool - > c_handle , slots ) ;
2018-05-12 02:01:46 +03:00
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 ) ;
2022-04-29 09:40:43 +03:00
if ( list_empty ( & zhdr - > buddy ) )
add_to_unbuddied ( pool , zhdr ) ;
2019-09-24 01:33:02 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2022-04-29 09:40:43 +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 ;
2019-12-01 04:56:11 +03:00
zhdr = get_z3fold_header ( handle ) ;
2016-05-21 02:58:30 +03:00
addr = zhdr ;
page = virt_to_page ( zhdr ) ;
if ( test_bit ( PAGE_HEADLESS , & page - > private ) )
goto out ;
buddy = handle_to_buddy ( handle ) ;
switch ( buddy ) {
case FIRST :
addr + = ZHDR_SIZE_ALIGNED ;
break ;
case MIDDLE :
addr + = zhdr - > start_middle < < CHUNK_SHIFT ;
set_bit ( MIDDLE_CHUNK_MAPPED , & page - > private ) ;
break ;
case LAST :
2018-11-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 + + ;
2016-05-21 02:58:30 +03:00
out :
2019-12-01 04:56:11 +03:00
put_z3fold_header ( zhdr ) ;
2016-05-21 02:58:30 +03:00
return addr ;
}
/**
* z3fold_unmap ( ) - unmaps the allocation associated with the given handle
* @ pool : pool in which the allocation resides
* @ handle : handle associated with the allocation to be unmapped
*/
static void z3fold_unmap ( struct z3fold_pool * pool , unsigned long handle )
{
struct z3fold_header * zhdr ;
struct page * page ;
enum buddy buddy ;
2019-12-01 04:56:11 +03:00
zhdr = get_z3fold_header ( handle ) ;
2016-05-21 02:58:30 +03:00
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 ;
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 - - ;
2019-12-01 04:56:11 +03:00
put_z3fold_header ( 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 ) ;
2020-12-15 06:12:33 +03:00
if ( test_bit ( PAGE_HEADLESS , & page - > private ) )
2019-05-14 03:22:52 +03:00
return false ;
zhdr = page_address ( page ) ;
z3fold_page_lock ( zhdr ) ;
if ( test_bit ( NEEDS_COMPACTING , & page - > private ) | |
test_bit ( PAGE_STALE , & page - > private ) )
goto out ;
2019-12-01 04:56:11 +03:00
if ( zhdr - > mapped_count ! = 0 | | zhdr - > foreign_handles ! = 0 )
goto out ;
2020-12-15 06:12:33 +03:00
if ( test_and_set_bit ( PAGE_CLAIMED , & page - > private ) )
goto out ;
2019-05-14 03:22:52 +03:00
pool = zhdr_to_pool ( zhdr ) ;
2019-12-01 04:56:11 +03:00
spin_lock ( & pool - > lock ) ;
if ( ! list_empty ( & zhdr - > buddy ) )
list_del_init ( & zhdr - > buddy ) ;
if ( ! list_empty ( & page - > lru ) )
list_del_init ( & page - > lru ) ;
spin_unlock ( & pool - > lock ) ;
kref_get ( & zhdr - > refcount ) ;
z3fold_page_unlock ( zhdr ) ;
return true ;
2019-05-14 03:22:52 +03:00
out :
z3fold_page_unlock ( zhdr ) ;
return false ;
}
2022-06-07 22:38:48 +03:00
static int z3fold_page_migrate ( struct page * newpage , struct page * page ,
enum migrate_mode mode )
2019-05-14 03:22:52 +03:00
{
struct z3fold_header * zhdr , * new_zhdr ;
struct z3fold_pool * pool ;
VM_BUG_ON_PAGE ( ! PageMovable ( page ) , page ) ;
VM_BUG_ON_PAGE ( ! PageIsolated ( page ) , page ) ;
2020-12-15 06:12:33 +03:00
VM_BUG_ON_PAGE ( ! test_bit ( PAGE_CLAIMED , & page - > private ) , page ) ;
2019-07-12 06:52:14 +03:00
VM_BUG_ON_PAGE ( ! PageLocked ( newpage ) , newpage ) ;
2019-05-14 03:22:52 +03:00
zhdr = page_address ( page ) ;
pool = zhdr_to_pool ( zhdr ) ;
2020-12-15 06:12:33 +03:00
if ( ! z3fold_page_trylock ( zhdr ) )
2019-05-14 03:22:52 +03:00
return - EAGAIN ;
2019-12-01 04:56:11 +03:00
if ( zhdr - > mapped_count ! = 0 | | zhdr - > foreign_handles ! = 0 ) {
2020-12-15 06:12:33 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2022-04-29 09:40:43 +03:00
z3fold_page_unlock ( zhdr ) ;
2019-05-14 03:22:52 +03:00
return - EBUSY ;
}
2019-07-17 02:26:21 +03:00
if ( work_pending ( & zhdr - > work ) ) {
z3fold_page_unlock ( zhdr ) ;
return - EAGAIN ;
}
2019-05-14 03:22:52 +03:00
new_zhdr = page_address ( newpage ) ;
memcpy ( new_zhdr , zhdr , PAGE_SIZE ) ;
newpage - > private = page - > private ;
2022-04-29 09:40:43 +03:00
set_bit ( PAGE_MIGRATED , & page - > private ) ;
2019-05-14 03:22:52 +03:00
z3fold_page_unlock ( zhdr ) ;
spin_lock_init ( & new_zhdr - > page_lock ) ;
2019-07-17 02:26:21 +03:00
INIT_WORK ( & new_zhdr - > work , compact_page_work ) ;
/*
* z3fold_page_isolate ( ) ensures that new_zhdr - > buddy is empty ,
* so we only have to reinitialize it .
*/
INIT_LIST_HEAD ( & new_zhdr - > buddy ) ;
2019-05-14 03:22:52 +03:00
__ClearPageMovable ( page ) ;
get_page ( newpage ) ;
z3fold_page_lock ( new_zhdr ) ;
if ( new_zhdr - > first_chunks )
encode_handle ( new_zhdr , FIRST ) ;
if ( new_zhdr - > last_chunks )
encode_handle ( new_zhdr , LAST ) ;
if ( new_zhdr - > middle_chunks )
encode_handle ( new_zhdr , MIDDLE ) ;
set_bit ( NEEDS_COMPACTING , & newpage - > private ) ;
new_zhdr - > cpu = smp_processor_id ( ) ;
spin_lock ( & pool - > lock ) ;
list_add ( & newpage - > lru , & pool - > lru ) ;
spin_unlock ( & pool - > lock ) ;
2022-06-07 22:38:48 +03:00
__SetPageMovable ( newpage , & z3fold_mops ) ;
2019-05-14 03:22:52 +03:00
z3fold_page_unlock ( new_zhdr ) ;
queue_work_on ( new_zhdr - > cpu , pool - > compact_wq , & new_zhdr - > work ) ;
2022-04-29 09:40:43 +03:00
/* PAGE_CLAIMED and PAGE_MIGRATED are cleared now. */
page - > private = 0 ;
2019-05-14 03:22:52 +03:00
put_page ( page ) ;
return 0 ;
}
static void z3fold_page_putback ( struct page * page )
{
struct z3fold_header * zhdr ;
struct z3fold_pool * pool ;
zhdr = page_address ( page ) ;
pool = zhdr_to_pool ( zhdr ) ;
z3fold_page_lock ( zhdr ) ;
if ( ! list_empty ( & zhdr - > buddy ) )
list_del_init ( & zhdr - > buddy ) ;
INIT_LIST_HEAD ( & page - > lru ) ;
2022-04-29 09:16:05 +03:00
if ( kref_put ( & zhdr - > refcount , release_z3fold_page_locked ) )
2019-05-14 03:22:52 +03:00
return ;
spin_lock ( & pool - > lock ) ;
list_add ( & page - > lru , & pool - > lru ) ;
spin_unlock ( & pool - > lock ) ;
2022-04-29 09:40:43 +03:00
if ( list_empty ( & zhdr - > buddy ) )
add_to_unbuddied ( pool , zhdr ) ;
2020-12-15 06:12:33 +03:00
clear_bit ( PAGE_CLAIMED , & page - > private ) ;
2019-05-14 03:22:52 +03:00
z3fold_page_unlock ( zhdr ) ;
}
2022-06-07 22:38:48 +03:00
static const struct movable_operations z3fold_mops = {
2019-05-14 03:22:52 +03:00
. isolate_page = z3fold_page_isolate ,
2022-06-07 22:38:48 +03:00
. migrate_page = z3fold_page_migrate ,
2019-05-14 03:22:52 +03:00
. 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 " ,
2021-02-26 04:18:22 +03:00
. sleep_mapped = true ,
2016-05-21 02:58:30 +03:00
. 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 )
{
2021-07-01 04:50:27 +03:00
/*
* Make sure the z3fold header is not larger than the page size and
* there has remaining spaces for its buddy .
*/
BUILD_BUG_ON ( ZHDR_SIZE_ALIGNED > PAGE_SIZE - CHUNK_SIZE ) ;
2016-05-21 02:58:30 +03:00
zpool_register_driver ( & z3fold_zpool_driver ) ;
return 0 ;
}
static void __exit exit_z3fold ( void )
{
zpool_unregister_driver ( & z3fold_zpool_driver ) ;
}
module_init ( init_z3fold ) ;
module_exit ( exit_z3fold ) ;
MODULE_LICENSE ( " GPL " ) ;
MODULE_AUTHOR ( " Vitaly Wool <vitalywool@gmail.com> " ) ;
MODULE_DESCRIPTION ( " 3-Fold Allocator for Compressed Pages " ) ;