2012-01-10 02:51:56 +04:00
/*
* zsmalloc memory allocator
*
* Copyright ( C ) 2011 Nitin Gupta
2014-01-31 03:45:55 +04:00
* Copyright ( C ) 2012 , 2013 Minchan Kim
2012-01-10 02:51:56 +04:00
*
* This code is released using a dual license strategy : BSD / GPL
* You can choose the license that better fits your requirements .
*
* Released under the terms of 3 - clause BSD License
* Released under the terms of GNU General Public License Version 2.0
*/
2012-06-10 04:41:14 +04:00
/*
* Following is how we use various fields and flags of underlying
* struct page ( s ) to form a zspage .
*
* Usage of struct page fields :
2016-07-27 01:23:23 +03:00
* page - > private : points to zspage
* page - > index : offset of the first object starting in this page .
* For the first page , this is always 0 , so we use this field
* to store handle for huge object .
* page - > next : links together all component pages of a zspage
2012-06-10 04:41:14 +04:00
*
* Usage of struct page flags :
* PG_private : identifies the first component page
* PG_private2 : identifies the last component page
*
*/
2016-05-27 01:16:27 +03:00
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2012-01-10 02:51:56 +04:00
# include <linux/module.h>
# include <linux/kernel.h>
2015-04-16 02:15:30 +03:00
# include <linux/sched.h>
2012-01-10 02:51:56 +04:00
# include <linux/bitops.h>
# include <linux/errno.h>
# include <linux/highmem.h>
# include <linux/string.h>
# include <linux/slab.h>
# include <asm/tlbflush.h>
# include <asm/pgtable.h>
# include <linux/cpumask.h>
# include <linux/cpu.h>
2012-02-13 18:47:49 +04:00
# include <linux/vmalloc.h>
2015-11-07 03:29:29 +03:00
# include <linux/preempt.h>
2012-08-08 10:12:17 +04:00
# include <linux/spinlock.h>
# include <linux/types.h>
2015-02-13 02:00:54 +03:00
# include <linux/debugfs.h>
2014-01-31 03:45:50 +04:00
# include <linux/zsmalloc.h>
2014-08-07 03:08:38 +04:00
# include <linux/zpool.h>
2012-08-08 10:12:17 +04:00
/*
* This must be power of 2 and greater than of equal to sizeof ( link_free ) .
* These two conditions ensure that any ' struct link_free ' itself doesn ' t
* span more than 1 page which avoids complex case of mapping 2 pages simply
* to restore link_free pointer values .
*/
# define ZS_ALIGN 8
/*
* A single ' zspage ' is composed of up to 2 ^ N discontiguous 0 - order ( single )
* pages . ZS_MAX_ZSPAGE_ORDER defines upper limit on N .
*/
# define ZS_MAX_ZSPAGE_ORDER 2
# define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
# define ZS_HANDLE_SIZE (sizeof(unsigned long))
2012-08-08 10:12:17 +04:00
/*
* Object location ( < PFN > , < obj_idx > ) is encoded as
2013-12-11 06:04:37 +04:00
* as single ( unsigned long ) handle value .
2012-08-08 10:12:17 +04:00
*
* Note that object index < obj_idx > is relative to system
* page < PFN > it is stored in , so for each sub - page belonging
* to a zspage , obj_idx starts with 0.
*
* This is made more complicated by various memory models and PAE .
*/
# ifndef MAX_PHYSMEM_BITS
# ifdef CONFIG_HIGHMEM64G
# define MAX_PHYSMEM_BITS 36
# else /* !CONFIG_HIGHMEM64G */
/*
* If this definition of MAX_PHYSMEM_BITS is used , OBJ_INDEX_BITS will just
* be PAGE_SHIFT
*/
# define MAX_PHYSMEM_BITS BITS_PER_LONG
# endif
# endif
# define _PFN_BITS (MAX_PHYSMEM_BITS - PAGE_SHIFT)
2015-04-16 02:15:30 +03:00
/*
* Memory for allocating for handle keeps object position by
* encoding < page , obj_idx > and the encoded value has a room
* in least bit ( ie , look at obj_to_location ) .
* We use the bit to synchronize between object access by
* user and migration .
*/
# define HANDLE_PIN_BIT 0
/*
* Head in allocated object should have OBJ_ALLOCATED_TAG
* to identify the object was allocated or not .
* It ' s okay to add the status bit in the least bit because
* header keeps handle which is 4 byte - aligned address so we
* have room for two bit at least .
*/
# define OBJ_ALLOCATED_TAG 1
# define OBJ_TAG_BITS 1
# define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
2012-08-08 10:12:17 +04:00
# define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
# define MAX(a, b) ((a) >= (b) ? (a) : (b))
/* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
# define ZS_MIN_ALLOC_SIZE \
MAX ( 32 , ( ZS_MAX_PAGES_PER_ZSPAGE < < PAGE_SHIFT > > OBJ_INDEX_BITS ) )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
/* each chunk includes extra space to keep handle */
2015-04-16 02:15:39 +03:00
# define ZS_MAX_ALLOC_SIZE PAGE_SIZE
2012-08-08 10:12:17 +04:00
/*
2014-06-05 03:11:08 +04:00
* On systems with 4 K page size , this gives 255 size classes ! There is a
2012-08-08 10:12:17 +04:00
* trader - off here :
* - Large number of size classes is potentially wasteful as free page are
* spread across these classes
* - Small number of size classes causes large internal fragmentation
* - Probably its better to use specific size classes ( empirically
* determined ) . NOTE : all those class sizes must be set as multiple of
* ZS_ALIGN to make sure link_free itself never has to span 2 pages .
*
* ZS_MIN_ALLOC_SIZE and ZS_SIZE_CLASS_DELTA must be multiple of ZS_ALIGN
* ( reason above )
*/
2016-07-27 01:23:23 +03:00
# define ZS_SIZE_CLASS_DELTA (PAGE_SIZE >> CLASS_BITS)
2012-08-08 10:12:17 +04:00
/*
* We do not maintain any list for completely empty or full pages
*/
enum fullness_group {
ZS_ALMOST_FULL ,
ZS_ALMOST_EMPTY ,
ZS_EMPTY ,
ZS_FULL
} ;
2015-02-13 02:00:54 +03:00
enum zs_stat_type {
OBJ_ALLOCATED ,
OBJ_USED ,
2015-04-16 02:15:42 +03:00
CLASS_ALMOST_FULL ,
CLASS_ALMOST_EMPTY ,
2015-02-13 02:00:54 +03:00
} ;
2015-11-07 03:29:38 +03:00
# ifdef CONFIG_ZSMALLOC_STAT
# define NR_ZS_STAT_TYPE (CLASS_ALMOST_EMPTY + 1)
# else
# define NR_ZS_STAT_TYPE (OBJ_USED + 1)
# endif
2015-02-13 02:00:54 +03:00
struct zs_size_stat {
unsigned long objs [ NR_ZS_STAT_TYPE ] ;
} ;
2015-09-09 01:04:27 +03:00
# ifdef CONFIG_ZSMALLOC_STAT
static struct dentry * zs_stat_root ;
2015-02-13 02:00:54 +03:00
# endif
2014-12-13 03:57:01 +03:00
/*
* number of size_classes
*/
static int zs_size_classes ;
2012-08-08 10:12:17 +04:00
/*
* We assign a page to ZS_ALMOST_EMPTY fullness group when :
* n < = N / f , where
* n = number of allocated objects
* N = total number of objects zspage can store
2014-10-10 02:29:59 +04:00
* f = fullness_threshold_frac
2012-08-08 10:12:17 +04:00
*
* Similarly , we assign zspage to :
* ZS_ALMOST_FULL when n > N / f
* ZS_EMPTY when n = = 0
* ZS_FULL when n = = N
*
* ( see : fix_fullness_group ( ) )
*/
static const int fullness_threshold_frac = 4 ;
struct size_class {
2015-09-09 01:04:27 +03:00
spinlock_t lock ;
2016-07-27 01:23:23 +03:00
struct list_head fullness_list [ 2 ] ;
2012-08-08 10:12:17 +04:00
/*
* Size of objects stored in this class . Must be multiple
* of ZS_ALIGN .
*/
int size ;
2016-07-27 01:23:11 +03:00
int objs_per_zspage ;
2012-08-08 10:12:17 +04:00
unsigned int index ;
2015-02-13 02:00:54 +03:00
struct zs_size_stat stats ;
2012-08-08 10:12:17 +04:00
2016-01-15 02:22:40 +03:00
/* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
int pages_per_zspage ;
2015-09-09 01:04:27 +03:00
/* huge object: pages_per_zspage == 1 && maxobj_per_zspage == 1 */
bool huge ;
2012-08-08 10:12:17 +04:00
} ;
/*
* Placed within free objects to form a singly linked list .
2016-07-27 01:23:23 +03:00
* For every zspage , zspage - > freeobj gives head of this list .
2012-08-08 10:12:17 +04:00
*
* This must be power of 2 and less than or equal to ZS_ALIGN
*/
struct link_free {
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
union {
/*
* Position of next free chunk ( encodes < PFN , obj_idx > )
* It ' s valid for non - allocated object
*/
void * next ;
/*
* Handle of allocated object .
*/
unsigned long handle ;
} ;
2012-08-08 10:12:17 +04:00
} ;
struct zs_pool {
2015-11-07 03:29:21 +03:00
const char * name ;
2015-02-13 02:00:54 +03:00
2014-12-13 03:57:01 +03:00
struct size_class * * size_class ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
struct kmem_cache * handle_cachep ;
2016-07-27 01:23:23 +03:00
struct kmem_cache * zspage_cachep ;
2012-08-08 10:12:17 +04:00
zsmalloc: move pages_allocated to zs_pool
Currently, zram has no feature to limit memory so theoretically zram can
deplete system memory. Users have asked for a limit several times as even
without exhaustion zram makes it hard to control memory usage of the
platform. This patchset adds the feature.
Patch 1 makes zs_get_total_size_bytes faster because it would be used
frequently in later patches for the new feature.
Patch 2 changes zs_get_total_size_bytes's return unit from bytes to page
so that zsmalloc doesn't need unnecessary operation(ie, << PAGE_SHIFT).
Patch 3 adds new feature. I added the feature into zram layer, not
zsmalloc because limiation is zram's requirement, not zsmalloc so any
other user using zsmalloc(ie, zpool) shouldn't affected by unnecessary
branch of zsmalloc. In future, if every users of zsmalloc want the
feature, then, we could move the feature from client side to zsmalloc
easily but vice versa would be painful.
Patch 4 adds news facility to report maximum memory usage of zram so that
this avoids user polling frequently via /sys/block/zram0/ mem_used_total
and ensures transient max are not missed.
This patch (of 4):
pages_allocated has counted in size_class structure and when user of
zsmalloc want to see total_size_bytes, it should gather all of count from
each size_class to report the sum.
It's not bad if user don't see the value often but if user start to see
the value frequently, it would be not a good deal for performance pov.
This patch moves the count from size_class to zs_pool so it could reduce
memory footprint (from [255 * 8byte] to [sizeof(atomic_long_t)]).
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: <juno.choi@lge.com>
Cc: <seungho1.park@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Reviewed-by: David Horner <ds2horner@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-10 02:29:48 +04:00
atomic_long_t pages_allocated ;
2015-02-13 02:00:54 +03:00
2015-09-09 01:04:35 +03:00
struct zs_pool_stats stats ;
2015-09-09 01:04:41 +03:00
/* Compact classes */
struct shrinker shrinker ;
/*
* To signify that register_shrinker ( ) was successful
* and unregister_shrinker ( ) will not Oops .
*/
bool shrinker_enabled ;
2015-02-13 02:00:54 +03:00
# ifdef CONFIG_ZSMALLOC_STAT
struct dentry * stat_dentry ;
# endif
2012-08-08 10:12:17 +04:00
} ;
2012-01-10 02:51:56 +04:00
/*
* A zspage ' s class index and fullness group
* are encoded in its ( first ) page - > mapping
*/
2016-07-27 01:23:23 +03:00
# define FULLNESS_BITS 2
# define CLASS_BITS 8
2016-07-27 01:23:17 +03:00
2016-07-27 01:23:23 +03:00
struct zspage {
struct {
unsigned int fullness : FULLNESS_BITS ;
unsigned int class : CLASS_BITS ;
} ;
unsigned int inuse ;
void * freeobj ;
struct page * first_page ;
struct list_head list ; /* fullness list */
} ;
2012-01-10 02:51:56 +04:00
2012-07-18 20:55:56 +04:00
struct mapping_area {
2013-12-11 06:04:36 +04:00
# ifdef CONFIG_PGTABLE_MAPPING
2012-07-18 20:55:56 +04:00
struct vm_struct * vm ; /* vm area for mapping object that span pages */
# else
char * vm_buf ; /* copy buffer for objects that span pages */
# endif
char * vm_addr ; /* address of kmap_atomic()'ed pages */
enum zs_mapmode vm_mm ; /* mapping mode */
} ;
2016-07-27 01:23:23 +03:00
static int create_cache ( struct zs_pool * pool )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
{
pool - > handle_cachep = kmem_cache_create ( " zs_handle " , ZS_HANDLE_SIZE ,
0 , 0 , NULL ) ;
2016-07-27 01:23:23 +03:00
if ( ! pool - > handle_cachep )
return 1 ;
pool - > zspage_cachep = kmem_cache_create ( " zspage " , sizeof ( struct zspage ) ,
0 , 0 , NULL ) ;
if ( ! pool - > zspage_cachep ) {
kmem_cache_destroy ( pool - > handle_cachep ) ;
pool - > handle_cachep = NULL ;
return 1 ;
}
return 0 ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
}
2016-07-27 01:23:23 +03:00
static void destroy_cache ( struct zs_pool * pool )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
{
2015-09-09 01:04:55 +03:00
kmem_cache_destroy ( pool - > handle_cachep ) ;
2016-07-27 01:23:23 +03:00
kmem_cache_destroy ( pool - > zspage_cachep ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
}
2016-07-27 01:23:23 +03:00
static unsigned long cache_alloc_handle ( struct zs_pool * pool , gfp_t gfp )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
{
return ( unsigned long ) kmem_cache_alloc ( pool - > handle_cachep ,
2016-05-21 02:59:48 +03:00
gfp & ~ __GFP_HIGHMEM ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
}
2016-07-27 01:23:23 +03:00
static void cache_free_handle ( struct zs_pool * pool , unsigned long handle )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
{
kmem_cache_free ( pool - > handle_cachep , ( void * ) handle ) ;
}
2016-07-27 01:23:23 +03:00
static struct zspage * cache_alloc_zspage ( struct zs_pool * pool , gfp_t flags )
{
return kmem_cache_alloc ( pool - > zspage_cachep , flags & ~ __GFP_HIGHMEM ) ;
} ;
static void cache_free_zspage ( struct zs_pool * pool , struct zspage * zspage )
{
kmem_cache_free ( pool - > zspage_cachep , zspage ) ;
}
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
static void record_obj ( unsigned long handle , unsigned long obj )
{
2016-01-21 01:58:18 +03:00
/*
* lsb of @ obj represents handle lock while other bits
* represent object value the handle is pointing so
* updating shouldn ' t do store tearing .
*/
WRITE_ONCE ( * ( unsigned long * ) handle , obj ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
}
2014-08-07 03:08:38 +04:00
/* zpool driver */
# ifdef CONFIG_ZPOOL
2015-11-07 03:29:21 +03:00
static void * zs_zpool_create ( const char * name , gfp_t gfp ,
2015-09-09 01:05:03 +03:00
const struct zpool_ops * zpool_ops ,
2015-06-26 01:00:40 +03:00
struct zpool * zpool )
2014-08-07 03:08:38 +04:00
{
2016-05-21 02:59:48 +03:00
/*
* Ignore global gfp flags : zs_malloc ( ) may be invoked from
* different contexts and its caller must provide a valid
* gfp mask .
*/
return zs_create_pool ( name ) ;
2014-08-07 03:08:38 +04:00
}
static void zs_zpool_destroy ( void * pool )
{
zs_destroy_pool ( pool ) ;
}
static int zs_zpool_malloc ( void * pool , size_t size , gfp_t gfp ,
unsigned long * handle )
{
2016-05-21 02:59:48 +03:00
* handle = zs_malloc ( pool , size , gfp ) ;
2014-08-07 03:08:38 +04:00
return * handle ? 0 : - 1 ;
}
static void zs_zpool_free ( void * pool , unsigned long handle )
{
zs_free ( pool , handle ) ;
}
static int zs_zpool_shrink ( void * pool , unsigned int pages ,
unsigned int * reclaimed )
{
return - EINVAL ;
}
static void * zs_zpool_map ( void * pool , unsigned long handle ,
enum zpool_mapmode mm )
{
enum zs_mapmode zs_mm ;
switch ( mm ) {
case ZPOOL_MM_RO :
zs_mm = ZS_MM_RO ;
break ;
case ZPOOL_MM_WO :
zs_mm = ZS_MM_WO ;
break ;
case ZPOOL_MM_RW : /* fallthru */
default :
zs_mm = ZS_MM_RW ;
break ;
}
return zs_map_object ( pool , handle , zs_mm ) ;
}
static void zs_zpool_unmap ( void * pool , unsigned long handle )
{
zs_unmap_object ( pool , handle ) ;
}
static u64 zs_zpool_total_size ( void * pool )
{
2014-10-10 02:29:50 +04:00
return zs_get_total_pages ( pool ) < < PAGE_SHIFT ;
2014-08-07 03:08:38 +04:00
}
static struct zpool_driver zs_zpool_driver = {
. type = " zsmalloc " ,
. owner = THIS_MODULE ,
. create = zs_zpool_create ,
. destroy = zs_zpool_destroy ,
. malloc = zs_zpool_malloc ,
. free = zs_zpool_free ,
. shrink = zs_zpool_shrink ,
. map = zs_zpool_map ,
. unmap = zs_zpool_unmap ,
. total_size = zs_zpool_total_size ,
} ;
2014-08-30 02:18:40 +04:00
MODULE_ALIAS ( " zpool-zsmalloc " ) ;
2014-08-07 03:08:38 +04:00
# endif /* CONFIG_ZPOOL */
2015-04-16 02:15:42 +03:00
static unsigned int get_maxobj_per_zspage ( int size , int pages_per_zspage )
{
return pages_per_zspage * PAGE_SIZE / size ;
}
2012-01-10 02:51:56 +04:00
/* per-cpu VM mapping areas for zspage accesses that cross page boundaries */
static DEFINE_PER_CPU ( struct mapping_area , zs_map_area ) ;
static int is_first_page ( struct page * page )
{
2012-04-25 10:23:09 +04:00
return PagePrivate ( page ) ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
static inline int get_zspage_inuse ( struct zspage * zspage )
2016-07-27 01:23:17 +03:00
{
2016-07-27 01:23:23 +03:00
return zspage - > inuse ;
2016-07-27 01:23:17 +03:00
}
2016-07-27 01:23:23 +03:00
static inline void set_zspage_inuse ( struct zspage * zspage , int val )
2016-07-27 01:23:17 +03:00
{
2016-07-27 01:23:23 +03:00
zspage - > inuse = val ;
2016-07-27 01:23:17 +03:00
}
2016-07-27 01:23:23 +03:00
static inline void mod_zspage_inuse ( struct zspage * zspage , int val )
2016-07-27 01:23:17 +03:00
{
2016-07-27 01:23:23 +03:00
zspage - > inuse + = val ;
2016-07-27 01:23:17 +03:00
}
static inline int get_first_obj_offset ( struct page * page )
{
2016-07-27 01:23:23 +03:00
if ( is_first_page ( page ) )
return 0 ;
2016-07-27 01:23:17 +03:00
return page - > index ;
}
static inline void set_first_obj_offset ( struct page * page , int offset )
{
2016-07-27 01:23:23 +03:00
if ( is_first_page ( page ) )
return ;
2016-07-27 01:23:17 +03:00
page - > index = offset ;
}
2016-07-27 01:23:23 +03:00
static inline unsigned long get_freeobj ( struct zspage * zspage )
2016-07-27 01:23:17 +03:00
{
2016-07-27 01:23:23 +03:00
return ( unsigned long ) zspage - > freeobj ;
2016-07-27 01:23:17 +03:00
}
2016-07-27 01:23:23 +03:00
static inline void set_freeobj ( struct zspage * zspage , unsigned long obj )
2016-07-27 01:23:17 +03:00
{
2016-07-27 01:23:23 +03:00
zspage - > freeobj = ( void * ) obj ;
2016-07-27 01:23:17 +03:00
}
2016-07-27 01:23:23 +03:00
static void get_zspage_mapping ( struct zspage * zspage ,
2016-05-21 02:59:36 +03:00
unsigned int * class_idx ,
2012-01-10 02:51:56 +04:00
enum fullness_group * fullness )
{
2016-07-27 01:23:23 +03:00
* fullness = zspage - > fullness ;
* class_idx = zspage - > class ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
static void set_zspage_mapping ( struct zspage * zspage ,
2016-05-21 02:59:36 +03:00
unsigned int class_idx ,
2012-01-10 02:51:56 +04:00
enum fullness_group fullness )
{
2016-07-27 01:23:23 +03:00
zspage - > class = class_idx ;
zspage - > fullness = fullness ;
2012-01-10 02:51:56 +04:00
}
2013-12-11 06:04:37 +04:00
/*
* zsmalloc divides the pool into various size classes where each
* class maintains a list of zspages where each zspage is divided
* into equal sized chunks . Each allocation falls into one of these
* classes depending on its size . This function returns index of the
* size class which has chunk size big enough to hold the give size .
*/
2012-01-10 02:51:56 +04:00
static int get_size_class_index ( int size )
{
int idx = 0 ;
if ( likely ( size > ZS_MIN_ALLOC_SIZE ) )
idx = DIV_ROUND_UP ( size - ZS_MIN_ALLOC_SIZE ,
ZS_SIZE_CLASS_DELTA ) ;
2015-04-16 02:15:39 +03:00
return min ( zs_size_classes - 1 , idx ) ;
2012-01-10 02:51:56 +04:00
}
2015-04-16 02:15:42 +03:00
static inline void zs_stat_inc ( struct size_class * class ,
enum zs_stat_type type , unsigned long cnt )
{
2015-11-07 03:29:38 +03:00
if ( type < NR_ZS_STAT_TYPE )
class - > stats . objs [ type ] + = cnt ;
2015-04-16 02:15:42 +03:00
}
static inline void zs_stat_dec ( struct size_class * class ,
enum zs_stat_type type , unsigned long cnt )
{
2015-11-07 03:29:38 +03:00
if ( type < NR_ZS_STAT_TYPE )
class - > stats . objs [ type ] - = cnt ;
2015-04-16 02:15:42 +03:00
}
static inline unsigned long zs_stat_get ( struct size_class * class ,
enum zs_stat_type type )
{
2015-11-07 03:29:38 +03:00
if ( type < NR_ZS_STAT_TYPE )
return class - > stats . objs [ type ] ;
return 0 ;
2015-04-16 02:15:42 +03:00
}
2015-09-09 01:04:27 +03:00
# ifdef CONFIG_ZSMALLOC_STAT
2016-05-27 01:16:27 +03:00
static void __init zs_stat_init ( void )
2015-04-16 02:15:42 +03:00
{
2016-05-27 01:16:27 +03:00
if ( ! debugfs_initialized ( ) ) {
pr_warn ( " debugfs not available, stat dir not created \n " ) ;
return ;
}
2015-04-16 02:15:42 +03:00
zs_stat_root = debugfs_create_dir ( " zsmalloc " , NULL ) ;
if ( ! zs_stat_root )
2016-05-27 01:16:27 +03:00
pr_warn ( " debugfs 'zsmalloc' stat dir creation failed \n " ) ;
2015-04-16 02:15:42 +03:00
}
static void __exit zs_stat_exit ( void )
{
debugfs_remove_recursive ( zs_stat_root ) ;
}
2016-03-18 00:20:42 +03:00
static unsigned long zs_can_compact ( struct size_class * class ) ;
2015-04-16 02:15:42 +03:00
static int zs_stats_size_show ( struct seq_file * s , void * v )
{
int i ;
struct zs_pool * pool = s - > private ;
struct size_class * class ;
int objs_per_zspage ;
unsigned long class_almost_full , class_almost_empty ;
2016-03-18 00:20:42 +03:00
unsigned long obj_allocated , obj_used , pages_used , freeable ;
2015-04-16 02:15:42 +03:00
unsigned long total_class_almost_full = 0 , total_class_almost_empty = 0 ;
unsigned long total_objs = 0 , total_used_objs = 0 , total_pages = 0 ;
2016-03-18 00:20:42 +03:00
unsigned long total_freeable = 0 ;
2015-04-16 02:15:42 +03:00
2016-03-18 00:20:42 +03:00
seq_printf ( s , " %5s %5s %11s %12s %13s %10s %10s %16s %8s \n " ,
2015-04-16 02:15:42 +03:00
" class " , " size " , " almost_full " , " almost_empty " ,
" obj_allocated " , " obj_used " , " pages_used " ,
2016-03-18 00:20:42 +03:00
" pages_per_zspage " , " freeable " ) ;
2015-04-16 02:15:42 +03:00
for ( i = 0 ; i < zs_size_classes ; i + + ) {
class = pool - > size_class [ i ] ;
if ( class - > index ! = i )
continue ;
spin_lock ( & class - > lock ) ;
class_almost_full = zs_stat_get ( class , CLASS_ALMOST_FULL ) ;
class_almost_empty = zs_stat_get ( class , CLASS_ALMOST_EMPTY ) ;
obj_allocated = zs_stat_get ( class , OBJ_ALLOCATED ) ;
obj_used = zs_stat_get ( class , OBJ_USED ) ;
2016-03-18 00:20:42 +03:00
freeable = zs_can_compact ( class ) ;
2015-04-16 02:15:42 +03:00
spin_unlock ( & class - > lock ) ;
objs_per_zspage = get_maxobj_per_zspage ( class - > size ,
class - > pages_per_zspage ) ;
pages_used = obj_allocated / objs_per_zspage *
class - > pages_per_zspage ;
2016-03-18 00:20:42 +03:00
seq_printf ( s , " %5u %5u %11lu %12lu %13lu "
" %10lu %10lu %16d %8lu \n " ,
2015-04-16 02:15:42 +03:00
i , class - > size , class_almost_full , class_almost_empty ,
obj_allocated , obj_used , pages_used ,
2016-03-18 00:20:42 +03:00
class - > pages_per_zspage , freeable ) ;
2015-04-16 02:15:42 +03:00
total_class_almost_full + = class_almost_full ;
total_class_almost_empty + = class_almost_empty ;
total_objs + = obj_allocated ;
total_used_objs + = obj_used ;
total_pages + = pages_used ;
2016-03-18 00:20:42 +03:00
total_freeable + = freeable ;
2015-04-16 02:15:42 +03:00
}
seq_puts ( s , " \n " ) ;
2016-03-18 00:20:42 +03:00
seq_printf ( s , " %5s %5s %11lu %12lu %13lu %10lu %10lu %16s %8lu \n " ,
2015-04-16 02:15:42 +03:00
" Total " , " " , total_class_almost_full ,
total_class_almost_empty , total_objs ,
2016-03-18 00:20:42 +03:00
total_used_objs , total_pages , " " , total_freeable ) ;
2015-04-16 02:15:42 +03:00
return 0 ;
}
static int zs_stats_size_open ( struct inode * inode , struct file * file )
{
return single_open ( file , zs_stats_size_show , inode - > i_private ) ;
}
static const struct file_operations zs_stat_size_ops = {
. open = zs_stats_size_open ,
. read = seq_read ,
. llseek = seq_lseek ,
. release = single_release ,
} ;
2016-05-21 02:59:56 +03:00
static void zs_pool_stat_create ( struct zs_pool * pool , const char * name )
2015-04-16 02:15:42 +03:00
{
struct dentry * entry ;
2016-05-27 01:16:27 +03:00
if ( ! zs_stat_root ) {
pr_warn ( " no root stat dir, not creating <%s> stat dir \n " , name ) ;
2016-05-21 02:59:56 +03:00
return ;
2016-05-27 01:16:27 +03:00
}
2015-04-16 02:15:42 +03:00
entry = debugfs_create_dir ( name , zs_stat_root ) ;
if ( ! entry ) {
pr_warn ( " debugfs dir <%s> creation failed \n " , name ) ;
2016-05-21 02:59:56 +03:00
return ;
2015-04-16 02:15:42 +03:00
}
pool - > stat_dentry = entry ;
entry = debugfs_create_file ( " classes " , S_IFREG | S_IRUGO ,
pool - > stat_dentry , pool , & zs_stat_size_ops ) ;
if ( ! entry ) {
pr_warn ( " %s: debugfs file entry <%s> creation failed \n " ,
name , " classes " ) ;
2016-05-27 01:16:27 +03:00
debugfs_remove_recursive ( pool - > stat_dentry ) ;
pool - > stat_dentry = NULL ;
2015-04-16 02:15:42 +03:00
}
}
static void zs_pool_stat_destroy ( struct zs_pool * pool )
{
debugfs_remove_recursive ( pool - > stat_dentry ) ;
}
# else /* CONFIG_ZSMALLOC_STAT */
2016-05-27 01:16:27 +03:00
static void __init zs_stat_init ( void )
2015-04-16 02:15:42 +03:00
{
}
static void __exit zs_stat_exit ( void )
{
}
2016-05-21 02:59:56 +03:00
static inline void zs_pool_stat_create ( struct zs_pool * pool , const char * name )
2015-04-16 02:15:42 +03:00
{
}
static inline void zs_pool_stat_destroy ( struct zs_pool * pool )
{
}
# endif
2013-12-11 06:04:37 +04:00
/*
* For each size class , zspages are divided into different groups
* depending on how " full " they are . This was done so that we could
* easily find empty or nearly empty zspages when we try to shrink
* the pool ( not yet implemented ) . This function returns fullness
* status of the given page .
*/
2016-07-27 01:23:11 +03:00
static enum fullness_group get_fullness_group ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:11 +03:00
int inuse , objs_per_zspage ;
2012-01-10 02:51:56 +04:00
enum fullness_group fg ;
2016-05-21 02:59:39 +03:00
2016-07-27 01:23:23 +03:00
inuse = get_zspage_inuse ( zspage ) ;
2016-07-27 01:23:11 +03:00
objs_per_zspage = class - > objs_per_zspage ;
2012-01-10 02:51:56 +04:00
if ( inuse = = 0 )
fg = ZS_EMPTY ;
2016-07-27 01:23:11 +03:00
else if ( inuse = = objs_per_zspage )
2012-01-10 02:51:56 +04:00
fg = ZS_FULL ;
2016-07-27 01:23:11 +03:00
else if ( inuse < = 3 * objs_per_zspage / fullness_threshold_frac )
2012-01-10 02:51:56 +04:00
fg = ZS_ALMOST_EMPTY ;
else
fg = ZS_ALMOST_FULL ;
return fg ;
}
2013-12-11 06:04:37 +04:00
/*
* Each size class maintains various freelists and zspages are assigned
* to one of these freelists based on the number of live objects they
* have . This functions inserts the given zspage into the freelist
* identified by < class , fullness_group > .
*/
2016-05-21 02:59:42 +03:00
static void insert_zspage ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage ,
enum fullness_group fullness )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
struct zspage * head ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
if ( fullness > = ZS_EMPTY )
2012-01-10 02:51:56 +04:00
return ;
2016-07-27 01:23:23 +03:00
head = list_first_entry_or_null ( & class - > fullness_list [ fullness ] ,
struct zspage , list ) ;
2015-04-16 02:15:42 +03:00
zs_stat_inc ( class , fullness = = ZS_ALMOST_EMPTY ?
CLASS_ALMOST_EMPTY : CLASS_ALMOST_FULL , 1 ) ;
2015-09-09 01:04:44 +03:00
/*
2016-07-27 01:23:23 +03:00
* We want to see more ZS_FULL pages and less almost empty / full .
* Put pages with higher - > inuse first .
2015-09-09 01:04:44 +03:00
*/
2016-07-27 01:23:23 +03:00
if ( head ) {
if ( get_zspage_inuse ( zspage ) < get_zspage_inuse ( head ) ) {
list_add ( & zspage - > list , & head - > list ) ;
return ;
}
}
list_add ( & zspage - > list , & class - > fullness_list [ fullness ] ) ;
2012-01-10 02:51:56 +04:00
}
2013-12-11 06:04:37 +04:00
/*
* This function removes the given zspage from the freelist identified
* by < class , fullness_group > .
*/
2016-05-21 02:59:42 +03:00
static void remove_zspage ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage ,
enum fullness_group fullness )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
if ( fullness > = ZS_EMPTY )
2012-01-10 02:51:56 +04:00
return ;
2016-07-27 01:23:23 +03:00
VM_BUG_ON ( list_empty ( & class - > fullness_list [ fullness ] ) ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
list_del_init ( & zspage - > list ) ;
2015-04-16 02:15:42 +03:00
zs_stat_dec ( class , fullness = = ZS_ALMOST_EMPTY ?
CLASS_ALMOST_EMPTY : CLASS_ALMOST_FULL , 1 ) ;
2012-01-10 02:51:56 +04:00
}
2013-12-11 06:04:37 +04:00
/*
* Each size class maintains zspages in different fullness groups depending
* on the number of live objects they contain . When allocating or freeing
* objects , the fullness status of the page can change , say , from ALMOST_FULL
* to ALMOST_EMPTY when freeing an object . This function checks if such
* a status change has occurred for the given page and accordingly moves the
* page from the freelist of the old fullness group to that of the new
* fullness group .
*/
2015-04-16 02:15:26 +03:00
static enum fullness_group fix_fullness_group ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage )
2012-01-10 02:51:56 +04:00
{
int class_idx ;
enum fullness_group currfg , newfg ;
2016-07-27 01:23:23 +03:00
get_zspage_mapping ( zspage , & class_idx , & currfg ) ;
newfg = get_fullness_group ( class , zspage ) ;
2012-01-10 02:51:56 +04:00
if ( newfg = = currfg )
goto out ;
2016-07-27 01:23:23 +03:00
remove_zspage ( class , zspage , currfg ) ;
insert_zspage ( class , zspage , newfg ) ;
set_zspage_mapping ( zspage , class_idx , newfg ) ;
2012-01-10 02:51:56 +04:00
out :
return newfg ;
}
/*
* We have to decide on how many pages to link together
* to form a zspage for each size class . This is important
* to reduce wastage due to unusable space left at end of
* each zspage which is given as :
2015-04-16 02:15:49 +03:00
* wastage = Zp % class_size
* usage = Zp - wastage
2012-01-10 02:51:56 +04:00
* where Zp = zspage size = k * PAGE_SIZE where k = 1 , 2 , . . .
*
* For example , for size class of 3 / 8 * PAGE_SIZE , we should
* link together 3 PAGE_SIZE sized pages to form a zspage
* since then we can perfectly fit in 8 such objects .
*/
2012-05-03 10:40:39 +04:00
static int get_pages_per_zspage ( int class_size )
2012-01-10 02:51:56 +04:00
{
int i , max_usedpc = 0 ;
/* zspage order which gives maximum used size per KB */
int max_usedpc_order = 1 ;
2012-03-05 21:33:21 +04:00
for ( i = 1 ; i < = ZS_MAX_PAGES_PER_ZSPAGE ; i + + ) {
2012-01-10 02:51:56 +04:00
int zspage_size ;
int waste , usedpc ;
zspage_size = i * PAGE_SIZE ;
waste = zspage_size % class_size ;
usedpc = ( zspage_size - waste ) * 100 / zspage_size ;
if ( usedpc > max_usedpc ) {
max_usedpc = usedpc ;
max_usedpc_order = i ;
}
}
return max_usedpc_order ;
}
2016-07-27 01:23:23 +03:00
static struct zspage * get_zspage ( struct page * page )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
return ( struct zspage * ) page - > private ;
2012-01-10 02:51:56 +04:00
}
static struct page * get_next_page ( struct page * page )
{
2016-07-27 01:23:23 +03:00
return page - > next ;
2012-01-10 02:51:56 +04:00
}
2013-11-22 21:30:41 +04:00
/*
* Encode < page , obj_idx > as a single handle value .
2015-04-16 02:15:30 +03:00
* We use the least bit of handle for tagging .
2013-11-22 21:30:41 +04:00
*/
2015-04-16 02:15:30 +03:00
static void * location_to_obj ( struct page * page , unsigned long obj_idx )
2012-01-10 02:51:56 +04:00
{
2015-04-16 02:15:30 +03:00
unsigned long obj ;
2012-01-10 02:51:56 +04:00
if ( ! page ) {
2016-05-21 02:59:39 +03:00
VM_BUG_ON ( obj_idx ) ;
2012-01-10 02:51:56 +04:00
return NULL ;
}
2015-04-16 02:15:30 +03:00
obj = page_to_pfn ( page ) < < OBJ_INDEX_BITS ;
obj | = ( ( obj_idx ) & OBJ_INDEX_MASK ) ;
obj < < = OBJ_TAG_BITS ;
2012-01-10 02:51:56 +04:00
2015-04-16 02:15:30 +03:00
return ( void * ) obj ;
2012-01-10 02:51:56 +04:00
}
2013-11-22 21:30:41 +04:00
/*
* Decode < page , obj_idx > pair from the given object handle . We adjust the
* decoded obj_idx back to its original value since it was adjusted in
2015-04-16 02:15:30 +03:00
* location_to_obj ( ) .
2013-11-22 21:30:41 +04:00
*/
2015-04-16 02:15:30 +03:00
static void obj_to_location ( unsigned long obj , struct page * * page ,
2012-01-10 02:51:56 +04:00
unsigned long * obj_idx )
{
2015-04-16 02:15:30 +03:00
obj > > = OBJ_TAG_BITS ;
* page = pfn_to_page ( obj > > OBJ_INDEX_BITS ) ;
* obj_idx = ( obj & OBJ_INDEX_MASK ) ;
2012-01-10 02:51:56 +04:00
}
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
static unsigned long handle_to_obj ( unsigned long handle )
{
return * ( unsigned long * ) handle ;
}
2015-04-16 02:15:39 +03:00
static unsigned long obj_to_head ( struct size_class * class , struct page * page ,
void * obj )
2015-04-16 02:15:30 +03:00
{
2015-04-16 02:15:39 +03:00
if ( class - > huge ) {
2016-05-21 02:59:39 +03:00
VM_BUG_ON_PAGE ( ! is_first_page ( page ) , page ) ;
2016-07-27 01:23:23 +03:00
return page - > index ;
2015-04-16 02:15:39 +03:00
} else
return * ( unsigned long * ) obj ;
2015-04-16 02:15:30 +03:00
}
2012-01-10 02:51:56 +04:00
static unsigned long obj_idx_to_offset ( struct page * page ,
unsigned long obj_idx , int class_size )
{
2016-07-27 01:23:23 +03:00
unsigned long off ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
off = get_first_obj_offset ( page ) ;
2012-01-10 02:51:56 +04:00
return off + obj_idx * class_size ;
}
2015-04-16 02:15:30 +03:00
static inline int trypin_tag ( unsigned long handle )
{
2016-07-27 01:23:14 +03:00
return bit_spin_trylock ( HANDLE_PIN_BIT , ( unsigned long * ) handle ) ;
2015-04-16 02:15:30 +03:00
}
static void pin_tag ( unsigned long handle )
{
2016-07-27 01:23:14 +03:00
bit_spin_lock ( HANDLE_PIN_BIT , ( unsigned long * ) handle ) ;
2015-04-16 02:15:30 +03:00
}
static void unpin_tag ( unsigned long handle )
{
2016-07-27 01:23:14 +03:00
bit_spin_unlock ( HANDLE_PIN_BIT , ( unsigned long * ) handle ) ;
2015-04-16 02:15:30 +03:00
}
2012-04-02 18:13:56 +04:00
static void reset_page ( struct page * page )
{
clear_bit ( PG_private , & page - > flags ) ;
clear_bit ( PG_private_2 , & page - > flags ) ;
set_page_private ( page , 0 ) ;
2016-07-27 01:23:23 +03:00
page - > index = 0 ;
2012-04-02 18:13:56 +04:00
}
2016-07-27 01:23:23 +03:00
static void free_zspage ( struct zs_pool * pool , struct zspage * zspage )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
struct page * page , * next ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
VM_BUG_ON ( get_zspage_inuse ( zspage ) ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
next = page = zspage - > first_page ;
do {
next = page - > next ;
reset_page ( page ) ;
put_page ( page ) ;
page = next ;
} while ( page ! = NULL ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
cache_free_zspage ( pool , zspage ) ;
2012-01-10 02:51:56 +04:00
}
/* Initialize a newly allocated zspage */
2016-07-27 01:23:23 +03:00
static void init_zspage ( struct size_class * class , struct zspage * zspage )
2012-01-10 02:51:56 +04:00
{
unsigned long off = 0 ;
2016-07-27 01:23:23 +03:00
struct page * page = zspage - > first_page ;
2016-05-21 02:59:39 +03:00
2012-01-10 02:51:56 +04:00
while ( page ) {
struct page * next_page ;
struct link_free * link ;
2014-10-10 02:30:01 +04:00
unsigned int i = 1 ;
2014-12-13 03:56:58 +03:00
void * vaddr ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
set_first_obj_offset ( page , off ) ;
2012-01-10 02:51:56 +04:00
2014-12-13 03:56:58 +03:00
vaddr = kmap_atomic ( page ) ;
link = ( struct link_free * ) vaddr + off / sizeof ( * link ) ;
2014-10-10 02:30:01 +04:00
while ( ( off + = class - > size ) < PAGE_SIZE ) {
2015-04-16 02:15:30 +03:00
link - > next = location_to_obj ( page , i + + ) ;
2014-10-10 02:30:01 +04:00
link + = class - > size / sizeof ( * link ) ;
2012-01-10 02:51:56 +04:00
}
/*
* We now come to the last ( full or partial ) object on this
* page , which must point to the first object on the next
* page ( if present )
*/
next_page = get_next_page ( page ) ;
2015-04-16 02:15:30 +03:00
link - > next = location_to_obj ( next_page , 0 ) ;
2014-12-13 03:56:58 +03:00
kunmap_atomic ( vaddr ) ;
2012-01-10 02:51:56 +04:00
page = next_page ;
2014-10-10 02:30:01 +04:00
off % = PAGE_SIZE ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:20 +03:00
2016-07-27 01:23:23 +03:00
set_freeobj ( zspage ,
( unsigned long ) location_to_obj ( zspage - > first_page , 0 ) ) ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
static void create_page_chain ( struct zspage * zspage , struct page * pages [ ] ,
int nr_pages )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:20 +03:00
int i ;
struct page * page ;
struct page * prev_page = NULL ;
2012-01-10 02:51:56 +04:00
/*
* Allocate individual pages and link them together as :
2016-07-27 01:23:23 +03:00
* 1. all pages are linked together using page - > next
* 2. each sub - page point to zspage using page - > private
2012-01-10 02:51:56 +04:00
*
2016-07-27 01:23:23 +03:00
* we set PG_private to identify the first page ( i . e . no other sub - page
* has this flag set ) and PG_private_2 to identify the last page .
2012-01-10 02:51:56 +04:00
*/
2016-07-27 01:23:20 +03:00
for ( i = 0 ; i < nr_pages ; i + + ) {
page = pages [ i ] ;
2016-07-27 01:23:23 +03:00
set_page_private ( page , ( unsigned long ) zspage ) ;
2016-07-27 01:23:20 +03:00
if ( i = = 0 ) {
2016-07-27 01:23:23 +03:00
zspage - > first_page = page ;
2012-04-25 10:23:09 +04:00
SetPagePrivate ( page ) ;
2016-07-27 01:23:23 +03:00
} else {
prev_page - > next = page ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
if ( i = = nr_pages - 1 ) {
2012-04-25 10:23:09 +04:00
SetPagePrivate2 ( page ) ;
2016-07-27 01:23:23 +03:00
page - > next = NULL ;
}
2012-01-10 02:51:56 +04:00
prev_page = page ;
}
2016-07-27 01:23:20 +03:00
}
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:20 +03:00
/*
* Allocate a zspage for the given size class
*/
2016-07-27 01:23:23 +03:00
static struct zspage * alloc_zspage ( struct zs_pool * pool ,
struct size_class * class ,
gfp_t gfp )
2016-07-27 01:23:20 +03:00
{
int i ;
struct page * pages [ ZS_MAX_PAGES_PER_ZSPAGE ] ;
2016-07-27 01:23:23 +03:00
struct zspage * zspage = cache_alloc_zspage ( pool , gfp ) ;
if ( ! zspage )
return NULL ;
memset ( zspage , 0 , sizeof ( struct zspage ) ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:20 +03:00
for ( i = 0 ; i < class - > pages_per_zspage ; i + + ) {
struct page * page ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
page = alloc_page ( gfp ) ;
2016-07-27 01:23:20 +03:00
if ( ! page ) {
while ( - - i > = 0 )
__free_page ( pages [ i ] ) ;
2016-07-27 01:23:23 +03:00
cache_free_zspage ( pool , zspage ) ;
2016-07-27 01:23:20 +03:00
return NULL ;
}
pages [ i ] = page ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
create_page_chain ( zspage , pages , class - > pages_per_zspage ) ;
init_zspage ( class , zspage ) ;
2016-07-27 01:23:20 +03:00
2016-07-27 01:23:23 +03:00
return zspage ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
static struct zspage * find_get_zspage ( struct size_class * class )
2012-01-10 02:51:56 +04:00
{
int i ;
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
for ( i = ZS_ALMOST_FULL ; i < = ZS_ALMOST_EMPTY ; i + + ) {
zspage = list_first_entry_or_null ( & class - > fullness_list [ i ] ,
struct zspage , list ) ;
if ( zspage )
2012-01-10 02:51:56 +04:00
break ;
}
2016-07-27 01:23:23 +03:00
return zspage ;
2012-01-10 02:51:56 +04:00
}
2013-12-11 06:04:36 +04:00
# ifdef CONFIG_PGTABLE_MAPPING
2012-07-18 20:55:56 +04:00
static inline int __zs_cpu_up ( struct mapping_area * area )
{
/*
* Make sure we don ' t leak memory if a cpu UP notification
* and zs_init ( ) race and both call zs_cpu_up ( ) on the same cpu
*/
if ( area - > vm )
return 0 ;
area - > vm = alloc_vm_area ( PAGE_SIZE * 2 , NULL ) ;
if ( ! area - > vm )
return - ENOMEM ;
return 0 ;
}
static inline void __zs_cpu_down ( struct mapping_area * area )
{
if ( area - > vm )
free_vm_area ( area - > vm ) ;
area - > vm = NULL ;
}
static inline void * __zs_map_object ( struct mapping_area * area ,
struct page * pages [ 2 ] , int off , int size )
{
2014-08-07 03:06:58 +04:00
BUG_ON ( map_vm_area ( area - > vm , PAGE_KERNEL , pages ) ) ;
2012-07-18 20:55:56 +04:00
area - > vm_addr = area - > vm - > addr ;
return area - > vm_addr + off ;
}
static inline void __zs_unmap_object ( struct mapping_area * area ,
struct page * pages [ 2 ] , int off , int size )
{
unsigned long addr = ( unsigned long ) area - > vm_addr ;
2013-03-27 04:43:14 +04:00
unmap_kernel_range ( addr , PAGE_SIZE * 2 ) ;
2012-07-18 20:55:56 +04:00
}
2013-12-11 06:04:36 +04:00
# else /* CONFIG_PGTABLE_MAPPING */
2012-07-18 20:55:56 +04:00
static inline int __zs_cpu_up ( struct mapping_area * area )
{
/*
* Make sure we don ' t leak memory if a cpu UP notification
* and zs_init ( ) race and both call zs_cpu_up ( ) on the same cpu
*/
if ( area - > vm_buf )
return 0 ;
2014-12-13 03:57:01 +03:00
area - > vm_buf = kmalloc ( ZS_MAX_ALLOC_SIZE , GFP_KERNEL ) ;
2012-07-18 20:55:56 +04:00
if ( ! area - > vm_buf )
return - ENOMEM ;
return 0 ;
}
static inline void __zs_cpu_down ( struct mapping_area * area )
{
2014-12-13 03:57:01 +03:00
kfree ( area - > vm_buf ) ;
2012-07-18 20:55:56 +04:00
area - > vm_buf = NULL ;
}
static void * __zs_map_object ( struct mapping_area * area ,
struct page * pages [ 2 ] , int off , int size )
2012-07-03 01:15:49 +04:00
{
int sizes [ 2 ] ;
void * addr ;
2012-07-18 20:55:56 +04:00
char * buf = area - > vm_buf ;
2012-07-03 01:15:49 +04:00
2012-07-18 20:55:56 +04:00
/* disable page faults to match kmap_atomic() return conditions */
pagefault_disable ( ) ;
/* no read fastpath */
if ( area - > vm_mm = = ZS_MM_WO )
goto out ;
2012-07-03 01:15:49 +04:00
sizes [ 0 ] = PAGE_SIZE - off ;
sizes [ 1 ] = size - sizes [ 0 ] ;
/* copy object to per-cpu buffer */
addr = kmap_atomic ( pages [ 0 ] ) ;
memcpy ( buf , addr + off , sizes [ 0 ] ) ;
kunmap_atomic ( addr ) ;
addr = kmap_atomic ( pages [ 1 ] ) ;
memcpy ( buf + sizes [ 0 ] , addr , sizes [ 1 ] ) ;
kunmap_atomic ( addr ) ;
2012-07-18 20:55:56 +04:00
out :
return area - > vm_buf ;
2012-07-03 01:15:49 +04:00
}
2012-07-18 20:55:56 +04:00
static void __zs_unmap_object ( struct mapping_area * area ,
struct page * pages [ 2 ] , int off , int size )
2012-07-03 01:15:49 +04:00
{
int sizes [ 2 ] ;
void * addr ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
char * buf ;
2012-07-03 01:15:49 +04:00
2012-07-18 20:55:56 +04:00
/* no write fastpath */
if ( area - > vm_mm = = ZS_MM_RO )
goto out ;
2012-07-03 01:15:49 +04:00
2015-04-16 02:15:39 +03:00
buf = area - > vm_buf ;
2016-03-18 00:20:39 +03:00
buf = buf + ZS_HANDLE_SIZE ;
size - = ZS_HANDLE_SIZE ;
off + = ZS_HANDLE_SIZE ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
2012-07-03 01:15:49 +04:00
sizes [ 0 ] = PAGE_SIZE - off ;
sizes [ 1 ] = size - sizes [ 0 ] ;
/* copy per-cpu buffer to object */
addr = kmap_atomic ( pages [ 0 ] ) ;
memcpy ( addr + off , buf , sizes [ 0 ] ) ;
kunmap_atomic ( addr ) ;
addr = kmap_atomic ( pages [ 1 ] ) ;
memcpy ( addr , buf + sizes [ 0 ] , sizes [ 1 ] ) ;
kunmap_atomic ( addr ) ;
2012-07-18 20:55:56 +04:00
out :
/* enable page faults to match kunmap_atomic() return conditions */
pagefault_enable ( ) ;
2012-07-03 01:15:49 +04:00
}
2012-01-10 02:51:56 +04:00
2013-12-11 06:04:36 +04:00
# endif /* CONFIG_PGTABLE_MAPPING */
2012-07-18 20:55:56 +04:00
2012-01-10 02:51:56 +04:00
static int zs_cpu_notifier ( struct notifier_block * nb , unsigned long action ,
void * pcpu )
{
2012-07-18 20:55:56 +04:00
int ret , cpu = ( long ) pcpu ;
2012-01-10 02:51:56 +04:00
struct mapping_area * area ;
switch ( action ) {
case CPU_UP_PREPARE :
area = & per_cpu ( zs_map_area , cpu ) ;
2012-07-18 20:55:56 +04:00
ret = __zs_cpu_up ( area ) ;
if ( ret )
return notifier_from_errno ( ret ) ;
2012-01-10 02:51:56 +04:00
break ;
case CPU_DEAD :
case CPU_UP_CANCELED :
area = & per_cpu ( zs_map_area , cpu ) ;
2012-07-18 20:55:56 +04:00
__zs_cpu_down ( area ) ;
2012-01-10 02:51:56 +04:00
break ;
}
return NOTIFY_OK ;
}
static struct notifier_block zs_cpu_nb = {
. notifier_call = zs_cpu_notifier
} ;
2014-12-13 03:56:56 +03:00
static int zs_register_cpu_notifier ( void )
2012-01-10 02:51:56 +04:00
{
2014-12-13 03:56:56 +03:00
int cpu , uninitialized_var ( ret ) ;
2012-01-10 02:51:56 +04:00
2014-03-11 00:39:59 +04:00
cpu_notifier_register_begin ( ) ;
__register_cpu_notifier ( & zs_cpu_nb ) ;
2012-01-10 02:51:56 +04:00
for_each_online_cpu ( cpu ) {
ret = zs_cpu_notifier ( NULL , CPU_UP_PREPARE , ( void * ) ( long ) cpu ) ;
2014-12-13 03:56:56 +03:00
if ( notifier_to_errno ( ret ) )
break ;
2012-01-10 02:51:56 +04:00
}
2014-03-11 00:39:59 +04:00
cpu_notifier_register_done ( ) ;
2014-12-13 03:56:56 +03:00
return notifier_to_errno ( ret ) ;
}
2014-03-11 00:39:59 +04:00
2014-12-19 03:17:40 +03:00
static void zs_unregister_cpu_notifier ( void )
2014-12-13 03:57:01 +03:00
{
2014-12-19 03:17:40 +03:00
int cpu ;
2014-12-13 03:57:01 +03:00
2014-12-19 03:17:40 +03:00
cpu_notifier_register_begin ( ) ;
2014-12-13 03:57:01 +03:00
2014-12-19 03:17:40 +03:00
for_each_online_cpu ( cpu )
zs_cpu_notifier ( NULL , CPU_DEAD , ( void * ) ( long ) cpu ) ;
__unregister_cpu_notifier ( & zs_cpu_nb ) ;
2014-12-13 03:57:01 +03:00
2014-12-19 03:17:40 +03:00
cpu_notifier_register_done ( ) ;
2014-12-13 03:56:56 +03:00
}
2014-12-19 03:17:40 +03:00
static void init_zs_size_classes ( void )
2014-12-13 03:56:56 +03:00
{
2014-12-19 03:17:40 +03:00
int nr ;
2014-08-07 03:08:38 +04:00
2014-12-19 03:17:40 +03:00
nr = ( ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE ) / ZS_SIZE_CLASS_DELTA + 1 ;
if ( ( ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE ) % ZS_SIZE_CLASS_DELTA )
nr + = 1 ;
2014-12-13 03:57:01 +03:00
2014-12-19 03:17:40 +03:00
zs_size_classes = nr ;
2012-01-10 02:51:56 +04:00
}
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
static bool can_merge ( struct size_class * prev , int size , int pages_per_zspage )
{
if ( prev - > pages_per_zspage ! = pages_per_zspage )
return false ;
if ( get_maxobj_per_zspage ( prev - > size , prev - > pages_per_zspage )
! = get_maxobj_per_zspage ( size , pages_per_zspage ) )
return false ;
return true ;
}
2016-07-27 01:23:23 +03:00
static bool zspage_full ( struct size_class * class , struct zspage * zspage )
2015-04-16 02:15:30 +03:00
{
2016-07-27 01:23:23 +03:00
return get_zspage_inuse ( zspage ) = = class - > objs_per_zspage ;
2015-04-16 02:15:30 +03:00
}
2014-12-19 03:17:40 +03:00
unsigned long zs_get_total_pages ( struct zs_pool * pool )
{
return atomic_long_read ( & pool - > pages_allocated ) ;
}
EXPORT_SYMBOL_GPL ( zs_get_total_pages ) ;
2013-01-05 00:14:00 +04:00
/**
2014-12-19 03:17:40 +03:00
* zs_map_object - get address of allocated object from handle .
* @ pool : pool from which the object was allocated
* @ handle : handle returned from zs_malloc
2013-01-05 00:14:00 +04:00
*
2014-12-19 03:17:40 +03:00
* Before using an object allocated from zs_malloc , it must be mapped using
* this function . When done with the object , it must be unmapped using
* zs_unmap_object .
2013-01-05 00:14:00 +04:00
*
2014-12-19 03:17:40 +03:00
* Only one object can be mapped per cpu at a time . There is no protection
* against nested mappings .
*
* This function returns with preemption and page faults disabled .
2013-01-05 00:14:00 +04:00
*/
2014-12-19 03:17:40 +03:00
void * zs_map_object ( struct zs_pool * pool , unsigned long handle ,
enum zs_mapmode mm )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
2014-12-19 03:17:40 +03:00
struct page * page ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
unsigned long obj , obj_idx , off ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
unsigned int class_idx ;
enum fullness_group fg ;
struct size_class * class ;
struct mapping_area * area ;
struct page * pages [ 2 ] ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
void * ret ;
2012-01-10 02:51:56 +04:00
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
/*
2014-12-19 03:17:40 +03:00
* Because we use per - cpu mapping areas shared among the
* pools / users , we can ' t allow mapping in interrupt context
* because it can corrupt another users mappings .
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
*/
2016-05-21 02:59:39 +03:00
WARN_ON_ONCE ( in_interrupt ( ) ) ;
2012-01-10 02:51:56 +04:00
2015-04-16 02:15:30 +03:00
/* From now on, migration cannot move the object */
pin_tag ( handle ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
obj = handle_to_obj ( handle ) ;
obj_to_location ( obj , & page , & obj_idx ) ;
2016-07-27 01:23:23 +03:00
zspage = get_zspage ( page ) ;
get_zspage_mapping ( zspage , & class_idx , & fg ) ;
2014-12-19 03:17:40 +03:00
class = pool - > size_class [ class_idx ] ;
off = obj_idx_to_offset ( page , obj_idx , class - > size ) ;
2014-12-13 03:57:07 +03:00
2014-12-19 03:17:40 +03:00
area = & get_cpu_var ( zs_map_area ) ;
area - > vm_mm = mm ;
if ( off + class - > size < = PAGE_SIZE ) {
/* this object is contained entirely within a page */
area - > vm_addr = kmap_atomic ( page ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
ret = area - > vm_addr + off ;
goto out ;
2012-01-10 02:51:56 +04:00
}
2014-12-19 03:17:40 +03:00
/* this object spans two pages */
pages [ 0 ] = page ;
pages [ 1 ] = get_next_page ( page ) ;
BUG_ON ( ! pages [ 1 ] ) ;
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
ret = __zs_map_object ( area , pages , off , class - > size ) ;
out :
2015-04-16 02:15:39 +03:00
if ( ! class - > huge )
ret + = ZS_HANDLE_SIZE ;
return ret ;
2012-01-10 02:51:56 +04:00
}
2014-12-19 03:17:40 +03:00
EXPORT_SYMBOL_GPL ( zs_map_object ) ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
void zs_unmap_object ( struct zs_pool * pool , unsigned long handle )
2012-01-10 02:51:56 +04:00
{
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
2014-12-19 03:17:40 +03:00
struct page * page ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
unsigned long obj , obj_idx , off ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
unsigned int class_idx ;
enum fullness_group fg ;
struct size_class * class ;
struct mapping_area * area ;
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
obj = handle_to_obj ( handle ) ;
obj_to_location ( obj , & page , & obj_idx ) ;
2016-07-27 01:23:23 +03:00
zspage = get_zspage ( page ) ;
get_zspage_mapping ( zspage , & class_idx , & fg ) ;
2014-12-19 03:17:40 +03:00
class = pool - > size_class [ class_idx ] ;
off = obj_idx_to_offset ( page , obj_idx , class - > size ) ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
area = this_cpu_ptr ( & zs_map_area ) ;
if ( off + class - > size < = PAGE_SIZE )
kunmap_atomic ( area - > vm_addr ) ;
else {
struct page * pages [ 2 ] ;
2014-12-13 03:57:01 +03:00
2014-12-19 03:17:40 +03:00
pages [ 0 ] = page ;
pages [ 1 ] = get_next_page ( page ) ;
BUG_ON ( ! pages [ 1 ] ) ;
__zs_unmap_object ( area , pages , off , class - > size ) ;
}
put_cpu_var ( zs_map_area ) ;
2015-04-16 02:15:30 +03:00
unpin_tag ( handle ) ;
2012-01-10 02:51:56 +04:00
}
2014-12-19 03:17:40 +03:00
EXPORT_SYMBOL_GPL ( zs_unmap_object ) ;
2012-01-10 02:51:56 +04:00
2016-05-21 02:59:42 +03:00
static unsigned long obj_malloc ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage , unsigned long handle )
2015-04-16 02:15:26 +03:00
{
unsigned long obj ;
struct link_free * link ;
struct page * m_page ;
unsigned long m_objidx , m_offset ;
void * vaddr ;
2015-04-16 02:15:30 +03:00
handle | = OBJ_ALLOCATED_TAG ;
2016-07-27 01:23:23 +03:00
obj = get_freeobj ( zspage ) ;
2015-04-16 02:15:26 +03:00
obj_to_location ( obj , & m_page , & m_objidx ) ;
m_offset = obj_idx_to_offset ( m_page , m_objidx , class - > size ) ;
vaddr = kmap_atomic ( m_page ) ;
link = ( struct link_free * ) vaddr + m_offset / sizeof ( * link ) ;
2016-07-27 01:23:23 +03:00
set_freeobj ( zspage , ( unsigned long ) link - > next ) ;
2015-04-16 02:15:39 +03:00
if ( ! class - > huge )
/* record handle in the header of allocated chunk */
link - > handle = handle ;
else
2016-07-27 01:23:23 +03:00
/* record handle to page->index */
zspage - > first_page - > index = handle ;
2015-04-16 02:15:26 +03:00
kunmap_atomic ( vaddr ) ;
2016-07-27 01:23:23 +03:00
mod_zspage_inuse ( zspage , 1 ) ;
2015-04-16 02:15:26 +03:00
zs_stat_inc ( class , OBJ_USED , 1 ) ;
return obj ;
}
2012-01-10 02:51:56 +04:00
/**
* zs_malloc - Allocate block of given size from pool .
* @ pool : pool to allocate from
* @ size : size of block to allocate
*
2012-05-03 10:40:40 +04:00
* On success , handle to the allocated object is returned ,
2012-06-08 10:39:25 +04:00
* otherwise 0.
2012-01-10 02:51:56 +04:00
* Allocation requests with size > ZS_MAX_ALLOC_SIZE will fail .
*/
2016-05-21 02:59:48 +03:00
unsigned long zs_malloc ( struct zs_pool * pool , size_t size , gfp_t gfp )
2012-01-10 02:51:56 +04:00
{
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
unsigned long handle , obj ;
2012-01-10 02:51:56 +04:00
struct size_class * class ;
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
2012-01-10 02:51:56 +04:00
2015-04-16 02:15:39 +03:00
if ( unlikely ( ! size | | size > ZS_MAX_ALLOC_SIZE ) )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
return 0 ;
2016-07-27 01:23:23 +03:00
handle = cache_alloc_handle ( pool , gfp ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
if ( ! handle )
2012-06-08 10:39:25 +04:00
return 0 ;
2012-01-10 02:51:56 +04:00
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
/* extra space in chunk to keep the handle */
size + = ZS_HANDLE_SIZE ;
zsmalloc: merge size_class to reduce fragmentation
zsmalloc has many size_classes to reduce fragmentation and they are in 16
bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. And,
zsmalloc has constraint that each zspage has 4 pages at maximum.
In this situation, we can see interesting aspect. Let's think about
size_class for 1488, 1472, ..., 1376. To prevent external fragmentation,
they uses 4 pages per zspage and so all they can contain 11 objects at
maximum.
16384 (4096 * 4) = 1488 * 11 + remains
16384 (4096 * 4) = 1472 * 11 + remains
16384 (4096 * 4) = ...
16384 (4096 * 4) = 1376 * 11 + remains
It means that they have same characteristics and classification between
them isn't needed. If we use one size_class for them, we can reduce
fragementation and save some memory since both the 1488 and 1472 sized
classes can only fit 11 objects into 4 pages, and an object that's 1472
bytes can fit into an object that's 1488 bytes, merging these classes to
always use objects that are 1488 bytes will reduce the total number of
size classes. And reducing the total number of size classes reduces
overall fragmentation, because a wider range of compressed pages can fit
into a single size class, leaving less unused objects in each size class.
For this purpose, this patch implement size_class merging. If there is
size_class that have same pages_per_zspage and same number of objects per
zspage with previous size_class, we don't create new size_class. Instead,
we use previous, same characteristic size_class. With this way, above
example sizes (1488, 1472, ..., 1376) use just one size_class so we can
get much more memory utilization.
Below is result of my simple test.
TEST ENV: EXT4 on zram, mount with discard option WORKLOAD: untar kernel
source code, remove directory in descending order in size. (drivers arch
fs sound include net Documentation firmware kernel tools)
Each line represents orig_data_size, compr_data_size, mem_used_total,
fragmentation overhead (mem_used - compr_data_size) and overhead ratio
(overhead to compr_data_size), respectively, after untar and remove
operation is executed.
* untar-nomerge.out
orig_size compr_size used_size overhead overhead_ratio
525.88MB 199.16MB 210.23MB 11.08MB 5.56%
288.32MB 97.43MB 105.63MB 8.20MB 8.41%
177.32MB 61.12MB 69.40MB 8.28MB 13.55%
146.47MB 47.32MB 56.10MB 8.78MB 18.55%
124.16MB 38.85MB 48.41MB 9.55MB 24.58%
103.93MB 31.68MB 40.93MB 9.25MB 29.21%
84.34MB 22.86MB 32.72MB 9.86MB 43.13%
66.87MB 14.83MB 23.83MB 9.00MB 60.70%
60.67MB 11.11MB 18.60MB 7.49MB 67.48%
55.86MB 8.83MB 16.61MB 7.77MB 88.03%
53.32MB 8.01MB 15.32MB 7.31MB 91.24%
* untar-merge.out
orig_size compr_size used_size overhead overhead_ratio
526.23MB 199.18MB 209.81MB 10.64MB 5.34%
288.68MB 97.45MB 104.08MB 6.63MB 6.80%
177.68MB 61.14MB 66.93MB 5.79MB 9.47%
146.83MB 47.34MB 52.79MB 5.45MB 11.51%
124.52MB 38.87MB 44.30MB 5.43MB 13.96%
104.29MB 31.70MB 36.83MB 5.13MB 16.19%
84.70MB 22.88MB 27.92MB 5.04MB 22.04%
67.11MB 14.83MB 19.26MB 4.43MB 29.86%
60.82MB 11.10MB 14.90MB 3.79MB 34.17%
55.90MB 8.82MB 12.61MB 3.79MB 42.97%
53.32MB 8.01MB 11.73MB 3.73MB 46.53%
As you can see above result, merged one has better utilization (overhead
ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: <juno.choi@lge.com>
Cc: "seungho1.park" <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-13 03:56:44 +03:00
class = pool - > size_class [ get_size_class_index ( size ) ] ;
2012-01-10 02:51:56 +04:00
spin_lock ( & class - > lock ) ;
2016-07-27 01:23:23 +03:00
zspage = find_get_zspage ( class ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
if ( ! zspage ) {
2012-01-10 02:51:56 +04:00
spin_unlock ( & class - > lock ) ;
2016-07-27 01:23:23 +03:00
zspage = alloc_zspage ( pool , class , gfp ) ;
if ( unlikely ( ! zspage ) ) {
cache_free_handle ( pool , handle ) ;
2012-06-08 10:39:25 +04:00
return 0 ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
}
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
set_zspage_mapping ( zspage , class - > index , ZS_EMPTY ) ;
zsmalloc: move pages_allocated to zs_pool
Currently, zram has no feature to limit memory so theoretically zram can
deplete system memory. Users have asked for a limit several times as even
without exhaustion zram makes it hard to control memory usage of the
platform. This patchset adds the feature.
Patch 1 makes zs_get_total_size_bytes faster because it would be used
frequently in later patches for the new feature.
Patch 2 changes zs_get_total_size_bytes's return unit from bytes to page
so that zsmalloc doesn't need unnecessary operation(ie, << PAGE_SHIFT).
Patch 3 adds new feature. I added the feature into zram layer, not
zsmalloc because limiation is zram's requirement, not zsmalloc so any
other user using zsmalloc(ie, zpool) shouldn't affected by unnecessary
branch of zsmalloc. In future, if every users of zsmalloc want the
feature, then, we could move the feature from client side to zsmalloc
easily but vice versa would be painful.
Patch 4 adds news facility to report maximum memory usage of zram so that
this avoids user polling frequently via /sys/block/zram0/ mem_used_total
and ensures transient max are not missed.
This patch (of 4):
pages_allocated has counted in size_class structure and when user of
zsmalloc want to see total_size_bytes, it should gather all of count from
each size_class to report the sum.
It's not bad if user don't see the value often but if user start to see
the value frequently, it would be not a good deal for performance pov.
This patch moves the count from size_class to zs_pool so it could reduce
memory footprint (from [255 * 8byte] to [sizeof(atomic_long_t)]).
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Dan Streetman <ddstreet@ieee.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: <juno.choi@lge.com>
Cc: <seungho1.park@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Reviewed-by: David Horner <ds2horner@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-10 02:29:48 +04:00
atomic_long_add ( class - > pages_per_zspage ,
& pool - > pages_allocated ) ;
2015-02-13 02:00:54 +03:00
2012-01-10 02:51:56 +04:00
spin_lock ( & class - > lock ) ;
2015-02-13 02:00:54 +03:00
zs_stat_inc ( class , OBJ_ALLOCATED , get_maxobj_per_zspage (
class - > size , class - > pages_per_zspage ) ) ;
2012-01-10 02:51:56 +04:00
}
2016-07-27 01:23:23 +03:00
obj = obj_malloc ( class , zspage , handle ) ;
2012-01-10 02:51:56 +04:00
/* Now move the zspage to another fullness group, if required */
2016-07-27 01:23:23 +03:00
fix_fullness_group ( class , zspage ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
record_obj ( handle , obj ) ;
2012-01-10 02:51:56 +04:00
spin_unlock ( & class - > lock ) ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
return handle ;
2012-01-10 02:51:56 +04:00
}
EXPORT_SYMBOL_GPL ( zs_malloc ) ;
2016-05-21 02:59:45 +03:00
static void obj_free ( struct size_class * class , unsigned long obj )
2012-01-10 02:51:56 +04:00
{
struct link_free * link ;
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
struct page * f_page ;
2015-04-16 02:15:26 +03:00
unsigned long f_objidx , f_offset ;
2014-12-13 03:56:58 +03:00
void * vaddr ;
2012-01-10 02:51:56 +04:00
2015-04-16 02:15:30 +03:00
obj & = ~ OBJ_ALLOCATED_TAG ;
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
obj_to_location ( obj , & f_page , & f_objidx ) ;
2016-07-27 01:23:23 +03:00
zspage = get_zspage ( f_page ) ;
2012-01-10 02:51:56 +04:00
f_offset = obj_idx_to_offset ( f_page , f_objidx , class - > size ) ;
2015-04-16 02:15:26 +03:00
vaddr = kmap_atomic ( f_page ) ;
2012-01-10 02:51:56 +04:00
/* Insert this object in containing zspage's freelist */
2014-12-13 03:56:58 +03:00
link = ( struct link_free * ) ( vaddr + f_offset ) ;
2016-07-27 01:23:23 +03:00
link - > next = ( void * ) get_freeobj ( zspage ) ;
2014-12-13 03:56:58 +03:00
kunmap_atomic ( vaddr ) ;
2016-07-27 01:23:23 +03:00
set_freeobj ( zspage , obj ) ;
mod_zspage_inuse ( zspage , - 1 ) ;
2015-02-13 02:00:54 +03:00
zs_stat_dec ( class , OBJ_USED , 1 ) ;
2015-04-16 02:15:26 +03:00
}
void zs_free ( struct zs_pool * pool , unsigned long handle )
{
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
struct page * f_page ;
2015-04-16 02:15:26 +03:00
unsigned long obj , f_objidx ;
int class_idx ;
struct size_class * class ;
enum fullness_group fullness ;
if ( unlikely ( ! handle ) )
return ;
2015-04-16 02:15:30 +03:00
pin_tag ( handle ) ;
2015-04-16 02:15:26 +03:00
obj = handle_to_obj ( handle ) ;
obj_to_location ( obj , & f_page , & f_objidx ) ;
2016-07-27 01:23:23 +03:00
zspage = get_zspage ( f_page ) ;
2015-04-16 02:15:26 +03:00
2016-07-27 01:23:23 +03:00
get_zspage_mapping ( zspage , & class_idx , & fullness ) ;
2015-04-16 02:15:26 +03:00
class = pool - > size_class [ class_idx ] ;
spin_lock ( & class - > lock ) ;
2016-05-21 02:59:45 +03:00
obj_free ( class , obj ) ;
2016-07-27 01:23:23 +03:00
fullness = fix_fullness_group ( class , zspage ) ;
2015-04-16 02:15:30 +03:00
if ( fullness = = ZS_EMPTY ) {
2015-02-13 02:00:54 +03:00
zs_stat_dec ( class , OBJ_ALLOCATED , get_maxobj_per_zspage (
class - > size , class - > pages_per_zspage ) ) ;
2015-04-16 02:15:30 +03:00
atomic_long_sub ( class - > pages_per_zspage ,
& pool - > pages_allocated ) ;
2016-07-27 01:23:23 +03:00
free_zspage ( pool , zspage ) ;
2015-04-16 02:15:30 +03:00
}
2012-01-10 02:51:56 +04:00
spin_unlock ( & class - > lock ) ;
2015-04-16 02:15:30 +03:00
unpin_tag ( handle ) ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
cache_free_handle ( pool , handle ) ;
2015-04-16 02:15:30 +03:00
}
EXPORT_SYMBOL_GPL ( zs_free ) ;
2016-05-21 02:59:42 +03:00
static void zs_object_copy ( struct size_class * class , unsigned long dst ,
unsigned long src )
2015-04-16 02:15:30 +03:00
{
struct page * s_page , * d_page ;
unsigned long s_objidx , d_objidx ;
unsigned long s_off , d_off ;
void * s_addr , * d_addr ;
int s_size , d_size , size ;
int written = 0 ;
s_size = d_size = class - > size ;
obj_to_location ( src , & s_page , & s_objidx ) ;
obj_to_location ( dst , & d_page , & d_objidx ) ;
s_off = obj_idx_to_offset ( s_page , s_objidx , class - > size ) ;
d_off = obj_idx_to_offset ( d_page , d_objidx , class - > size ) ;
if ( s_off + class - > size > PAGE_SIZE )
s_size = PAGE_SIZE - s_off ;
if ( d_off + class - > size > PAGE_SIZE )
d_size = PAGE_SIZE - d_off ;
s_addr = kmap_atomic ( s_page ) ;
d_addr = kmap_atomic ( d_page ) ;
while ( 1 ) {
size = min ( s_size , d_size ) ;
memcpy ( d_addr + d_off , s_addr + s_off , size ) ;
written + = size ;
if ( written = = class - > size )
break ;
2015-04-16 02:16:15 +03:00
s_off + = size ;
s_size - = size ;
d_off + = size ;
d_size - = size ;
if ( s_off > = PAGE_SIZE ) {
2015-04-16 02:15:30 +03:00
kunmap_atomic ( d_addr ) ;
kunmap_atomic ( s_addr ) ;
s_page = get_next_page ( s_page ) ;
s_addr = kmap_atomic ( s_page ) ;
d_addr = kmap_atomic ( d_page ) ;
s_size = class - > size - written ;
s_off = 0 ;
}
2015-04-16 02:16:15 +03:00
if ( d_off > = PAGE_SIZE ) {
2015-04-16 02:15:30 +03:00
kunmap_atomic ( d_addr ) ;
d_page = get_next_page ( d_page ) ;
d_addr = kmap_atomic ( d_page ) ;
d_size = class - > size - written ;
d_off = 0 ;
}
}
kunmap_atomic ( d_addr ) ;
kunmap_atomic ( s_addr ) ;
}
/*
* Find alloced object in zspage from index object and
* return handle .
*/
2016-05-21 02:59:42 +03:00
static unsigned long find_alloced_obj ( struct size_class * class ,
struct page * page , int index )
2015-04-16 02:15:30 +03:00
{
unsigned long head ;
int offset = 0 ;
unsigned long handle = 0 ;
void * addr = kmap_atomic ( page ) ;
2016-07-27 01:23:23 +03:00
offset = get_first_obj_offset ( page ) ;
2015-04-16 02:15:30 +03:00
offset + = class - > size * index ;
while ( offset < PAGE_SIZE ) {
2015-04-16 02:15:39 +03:00
head = obj_to_head ( class , page , addr + offset ) ;
2015-04-16 02:15:30 +03:00
if ( head & OBJ_ALLOCATED_TAG ) {
handle = head & ~ OBJ_ALLOCATED_TAG ;
if ( trypin_tag ( handle ) )
break ;
handle = 0 ;
}
offset + = class - > size ;
index + + ;
}
kunmap_atomic ( addr ) ;
return handle ;
}
struct zs_compact_control {
2016-07-27 01:23:23 +03:00
/* Source spage for migration which could be a subpage of zspage */
2015-04-16 02:15:30 +03:00
struct page * s_page ;
/* Destination page for migration which should be a first page
* of zspage . */
struct page * d_page ;
/* Starting object index within @s_page which used for live object
* in the subpage . */
int index ;
} ;
static int migrate_zspage ( struct zs_pool * pool , struct size_class * class ,
struct zs_compact_control * cc )
{
unsigned long used_obj , free_obj ;
unsigned long handle ;
struct page * s_page = cc - > s_page ;
struct page * d_page = cc - > d_page ;
unsigned long index = cc - > index ;
int ret = 0 ;
while ( 1 ) {
2016-05-21 02:59:42 +03:00
handle = find_alloced_obj ( class , s_page , index ) ;
2015-04-16 02:15:30 +03:00
if ( ! handle ) {
s_page = get_next_page ( s_page ) ;
if ( ! s_page )
break ;
index = 0 ;
continue ;
}
/* Stop if there is no more space */
2016-07-27 01:23:23 +03:00
if ( zspage_full ( class , get_zspage ( d_page ) ) ) {
2015-04-16 02:15:30 +03:00
unpin_tag ( handle ) ;
ret = - ENOMEM ;
break ;
}
used_obj = handle_to_obj ( handle ) ;
2016-07-27 01:23:23 +03:00
free_obj = obj_malloc ( class , get_zspage ( d_page ) , handle ) ;
2016-05-21 02:59:42 +03:00
zs_object_copy ( class , free_obj , used_obj ) ;
2015-04-16 02:15:30 +03:00
index + + ;
2016-01-21 01:58:18 +03:00
/*
* record_obj updates handle ' s value to free_obj and it will
* invalidate lock bit ( ie , HANDLE_PIN_BIT ) of handle , which
* breaks synchronization using pin_tag ( e , g , zs_free ) so
* let ' s keep the lock bit .
*/
free_obj | = BIT ( HANDLE_PIN_BIT ) ;
2015-04-16 02:15:30 +03:00
record_obj ( handle , free_obj ) ;
unpin_tag ( handle ) ;
2016-05-21 02:59:45 +03:00
obj_free ( class , used_obj ) ;
2015-04-16 02:15:30 +03:00
}
/* Remember last position in this iteration */
cc - > s_page = s_page ;
cc - > index = index ;
return ret ;
}
2016-07-27 01:23:23 +03:00
static struct zspage * isolate_zspage ( struct size_class * class , bool source )
2015-04-16 02:15:30 +03:00
{
int i ;
2016-07-27 01:23:23 +03:00
struct zspage * zspage ;
enum fullness_group fg [ 2 ] = { ZS_ALMOST_EMPTY , ZS_ALMOST_FULL } ;
2015-04-16 02:15:30 +03:00
2016-07-27 01:23:23 +03:00
if ( ! source ) {
fg [ 0 ] = ZS_ALMOST_FULL ;
fg [ 1 ] = ZS_ALMOST_EMPTY ;
}
for ( i = 0 ; i < 2 ; i + + ) {
zspage = list_first_entry_or_null ( & class - > fullness_list [ fg [ i ] ] ,
struct zspage , list ) ;
if ( zspage ) {
remove_zspage ( class , zspage , fg [ i ] ) ;
return zspage ;
2015-04-16 02:15:30 +03:00
}
}
2016-07-27 01:23:23 +03:00
return zspage ;
2015-04-16 02:15:30 +03:00
}
2015-09-09 01:04:38 +03:00
/*
2016-07-27 01:23:23 +03:00
* putback_zspage - add @ zspage into right class ' s fullness list
2015-09-09 01:04:38 +03:00
* @ class : destination class
2016-07-27 01:23:23 +03:00
* @ zspage : target page
2015-09-09 01:04:38 +03:00
*
2016-07-27 01:23:23 +03:00
* Return @ zspage ' s fullness_group
2015-09-09 01:04:38 +03:00
*/
2016-07-27 01:23:26 +03:00
static enum fullness_group putback_zspage ( struct size_class * class ,
2016-07-27 01:23:23 +03:00
struct zspage * zspage )
2015-04-16 02:15:30 +03:00
{
enum fullness_group fullness ;
2016-07-27 01:23:23 +03:00
fullness = get_fullness_group ( class , zspage ) ;
insert_zspage ( class , zspage , fullness ) ;
set_zspage_mapping ( zspage , class - > index , fullness ) ;
2015-04-16 02:16:18 +03:00
2015-09-09 01:04:38 +03:00
return fullness ;
2012-01-10 02:51:56 +04:00
}
2015-04-16 02:15:30 +03:00
2015-09-09 01:04:30 +03:00
/*
*
* Based on the number of unused allocated objects calculate
* and return the number of pages that we can free .
*/
static unsigned long zs_can_compact ( struct size_class * class )
{
unsigned long obj_wasted ;
zsmalloc: fix zs_can_compact() integer overflow
zs_can_compact() has two race conditions in its core calculation:
unsigned long obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);
1) classes are not locked, so the numbers of allocated and used
objects can change by the concurrent ops happening on other CPUs
2) shrinker invokes it from preemptible context
Depending on the circumstances, thus, OBJ_ALLOCATED can become
less than OBJ_USED, which can result in either very high or
negative `total_scan' value calculated later in do_shrink_slab().
do_shrink_slab() has some logic to prevent those cases:
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-64
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
However, due to the way `total_scan' is calculated, not every
shrinker->count_objects() overflow can be spotted and handled.
To demonstrate the latter, I added some debugging code to do_shrink_slab()
(x86_64) and the results were:
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 92679974445502
vmscan: resulting total_scan: 92679974445502
[..]
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 22634041808232578
vmscan: resulting total_scan: 22634041808232578
Even though shrinker->count_objects() has returned an overflowed value,
the resulting `total_scan' is positive, and, what is more worrisome, it
is insanely huge. This value is getting used later on in
shrinker->scan_objects() loop:
while (total_scan >= batch_size ||
total_scan >= freeable) {
unsigned long ret;
unsigned long nr_to_scan = min(batch_size, total_scan);
shrinkctl->nr_to_scan = nr_to_scan;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
count_vm_events(SLABS_SCANNED, nr_to_scan);
total_scan -= nr_to_scan;
cond_resched();
}
`total_scan >= batch_size' is true for a very-very long time and
'total_scan >= freeable' is also true for quite some time, because
`freeable < 0' and `total_scan' is large enough, for example,
22634041808232578. The only break condition, in the given scheme of
things, is shrinker->scan_objects() == SHRINK_STOP test, which is a
bit too weak to rely on, especially in heavy zsmalloc-usage scenarios.
To fix the issue, take a pool stat snapshot and use it instead of
racy zs_stat_get() calls.
Link: http://lkml.kernel.org/r/20160509140052.3389-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org> [4.3+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-10 02:28:49 +03:00
unsigned long obj_allocated = zs_stat_get ( class , OBJ_ALLOCATED ) ;
unsigned long obj_used = zs_stat_get ( class , OBJ_USED ) ;
2015-09-09 01:04:30 +03:00
zsmalloc: fix zs_can_compact() integer overflow
zs_can_compact() has two race conditions in its core calculation:
unsigned long obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);
1) classes are not locked, so the numbers of allocated and used
objects can change by the concurrent ops happening on other CPUs
2) shrinker invokes it from preemptible context
Depending on the circumstances, thus, OBJ_ALLOCATED can become
less than OBJ_USED, which can result in either very high or
negative `total_scan' value calculated later in do_shrink_slab().
do_shrink_slab() has some logic to prevent those cases:
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-64
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
However, due to the way `total_scan' is calculated, not every
shrinker->count_objects() overflow can be spotted and handled.
To demonstrate the latter, I added some debugging code to do_shrink_slab()
(x86_64) and the results were:
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 92679974445502
vmscan: resulting total_scan: 92679974445502
[..]
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 22634041808232578
vmscan: resulting total_scan: 22634041808232578
Even though shrinker->count_objects() has returned an overflowed value,
the resulting `total_scan' is positive, and, what is more worrisome, it
is insanely huge. This value is getting used later on in
shrinker->scan_objects() loop:
while (total_scan >= batch_size ||
total_scan >= freeable) {
unsigned long ret;
unsigned long nr_to_scan = min(batch_size, total_scan);
shrinkctl->nr_to_scan = nr_to_scan;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
count_vm_events(SLABS_SCANNED, nr_to_scan);
total_scan -= nr_to_scan;
cond_resched();
}
`total_scan >= batch_size' is true for a very-very long time and
'total_scan >= freeable' is also true for quite some time, because
`freeable < 0' and `total_scan' is large enough, for example,
22634041808232578. The only break condition, in the given scheme of
things, is shrinker->scan_objects() == SHRINK_STOP test, which is a
bit too weak to rely on, especially in heavy zsmalloc-usage scenarios.
To fix the issue, take a pool stat snapshot and use it instead of
racy zs_stat_get() calls.
Link: http://lkml.kernel.org/r/20160509140052.3389-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org> [4.3+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-10 02:28:49 +03:00
if ( obj_allocated < = obj_used )
return 0 ;
2015-09-09 01:04:30 +03:00
zsmalloc: fix zs_can_compact() integer overflow
zs_can_compact() has two race conditions in its core calculation:
unsigned long obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);
1) classes are not locked, so the numbers of allocated and used
objects can change by the concurrent ops happening on other CPUs
2) shrinker invokes it from preemptible context
Depending on the circumstances, thus, OBJ_ALLOCATED can become
less than OBJ_USED, which can result in either very high or
negative `total_scan' value calculated later in do_shrink_slab().
do_shrink_slab() has some logic to prevent those cases:
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-64
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
However, due to the way `total_scan' is calculated, not every
shrinker->count_objects() overflow can be spotted and handled.
To demonstrate the latter, I added some debugging code to do_shrink_slab()
(x86_64) and the results were:
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 92679974445502
vmscan: resulting total_scan: 92679974445502
[..]
vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
vmscan: but total_scan > 0: 22634041808232578
vmscan: resulting total_scan: 22634041808232578
Even though shrinker->count_objects() has returned an overflowed value,
the resulting `total_scan' is positive, and, what is more worrisome, it
is insanely huge. This value is getting used later on in
shrinker->scan_objects() loop:
while (total_scan >= batch_size ||
total_scan >= freeable) {
unsigned long ret;
unsigned long nr_to_scan = min(batch_size, total_scan);
shrinkctl->nr_to_scan = nr_to_scan;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
count_vm_events(SLABS_SCANNED, nr_to_scan);
total_scan -= nr_to_scan;
cond_resched();
}
`total_scan >= batch_size' is true for a very-very long time and
'total_scan >= freeable' is also true for quite some time, because
`freeable < 0' and `total_scan' is large enough, for example,
22634041808232578. The only break condition, in the given scheme of
things, is shrinker->scan_objects() == SHRINK_STOP test, which is a
bit too weak to rely on, especially in heavy zsmalloc-usage scenarios.
To fix the issue, take a pool stat snapshot and use it instead of
racy zs_stat_get() calls.
Link: http://lkml.kernel.org/r/20160509140052.3389-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org> [4.3+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-10 02:28:49 +03:00
obj_wasted = obj_allocated - obj_used ;
2015-09-09 01:04:30 +03:00
obj_wasted / = get_maxobj_per_zspage ( class - > size ,
class - > pages_per_zspage ) ;
2015-09-09 01:04:49 +03:00
return obj_wasted * class - > pages_per_zspage ;
2015-09-09 01:04:30 +03:00
}
2015-09-09 01:04:35 +03:00
static void __zs_compact ( struct zs_pool * pool , struct size_class * class )
2015-04-16 02:15:30 +03:00
{
struct zs_compact_control cc ;
2016-07-27 01:23:23 +03:00
struct zspage * src_zspage ;
struct zspage * dst_zspage = NULL ;
2015-04-16 02:15:30 +03:00
spin_lock ( & class - > lock ) ;
2016-07-27 01:23:23 +03:00
while ( ( src_zspage = isolate_zspage ( class , true ) ) ) {
2015-04-16 02:15:30 +03:00
2015-09-09 01:04:30 +03:00
if ( ! zs_can_compact ( class ) )
break ;
2015-04-16 02:15:30 +03:00
cc . index = 0 ;
2016-07-27 01:23:23 +03:00
cc . s_page = src_zspage - > first_page ;
2015-04-16 02:15:30 +03:00
2016-07-27 01:23:23 +03:00
while ( ( dst_zspage = isolate_zspage ( class , false ) ) ) {
cc . d_page = dst_zspage - > first_page ;
2015-04-16 02:15:30 +03:00
/*
2015-09-09 01:04:33 +03:00
* If there is no more space in dst_page , resched
* and see if anyone had allocated another zspage .
2015-04-16 02:15:30 +03:00
*/
if ( ! migrate_zspage ( pool , class , & cc ) )
break ;
2016-07-27 01:23:26 +03:00
putback_zspage ( class , dst_zspage ) ;
2015-04-16 02:15:30 +03:00
}
/* Stop if we couldn't find slot */
2016-07-27 01:23:23 +03:00
if ( dst_zspage = = NULL )
2015-04-16 02:15:30 +03:00
break ;
2016-07-27 01:23:26 +03:00
putback_zspage ( class , dst_zspage ) ;
if ( putback_zspage ( class , src_zspage ) = = ZS_EMPTY ) {
zs_stat_dec ( class , OBJ_ALLOCATED , get_maxobj_per_zspage (
class - > size , class - > pages_per_zspage ) ) ;
atomic_long_sub ( class - > pages_per_zspage ,
& pool - > pages_allocated ) ;
free_zspage ( pool , src_zspage ) ;
2015-09-09 01:04:49 +03:00
pool - > stats . pages_compacted + = class - > pages_per_zspage ;
2016-07-27 01:23:26 +03:00
}
2015-04-16 02:15:30 +03:00
spin_unlock ( & class - > lock ) ;
cond_resched ( ) ;
spin_lock ( & class - > lock ) ;
}
2016-07-27 01:23:23 +03:00
if ( src_zspage )
2016-07-27 01:23:26 +03:00
putback_zspage ( class , src_zspage ) ;
2015-04-16 02:15:30 +03:00
2015-09-09 01:04:35 +03:00
spin_unlock ( & class - > lock ) ;
2015-04-16 02:15:30 +03:00
}
unsigned long zs_compact ( struct zs_pool * pool )
{
int i ;
struct size_class * class ;
for ( i = zs_size_classes - 1 ; i > = 0 ; i - - ) {
class = pool - > size_class [ i ] ;
if ( ! class )
continue ;
if ( class - > index ! = i )
continue ;
2015-09-09 01:04:35 +03:00
__zs_compact ( pool , class ) ;
2015-04-16 02:15:30 +03:00
}
2015-09-09 01:04:38 +03:00
return pool - > stats . pages_compacted ;
2015-04-16 02:15:30 +03:00
}
EXPORT_SYMBOL_GPL ( zs_compact ) ;
2012-01-10 02:51:56 +04:00
2015-09-09 01:04:35 +03:00
void zs_pool_stats ( struct zs_pool * pool , struct zs_pool_stats * stats )
{
memcpy ( stats , & pool - > stats , sizeof ( struct zs_pool_stats ) ) ;
}
EXPORT_SYMBOL_GPL ( zs_pool_stats ) ;
2015-09-09 01:04:41 +03:00
static unsigned long zs_shrinker_scan ( struct shrinker * shrinker ,
struct shrink_control * sc )
{
unsigned long pages_freed ;
struct zs_pool * pool = container_of ( shrinker , struct zs_pool ,
shrinker ) ;
pages_freed = pool - > stats . pages_compacted ;
/*
* Compact classes and calculate compaction delta .
* Can run concurrently with a manually triggered
* ( by user ) compaction .
*/
pages_freed = zs_compact ( pool ) - pages_freed ;
return pages_freed ? pages_freed : SHRINK_STOP ;
}
static unsigned long zs_shrinker_count ( struct shrinker * shrinker ,
struct shrink_control * sc )
{
int i ;
struct size_class * class ;
unsigned long pages_to_free = 0 ;
struct zs_pool * pool = container_of ( shrinker , struct zs_pool ,
shrinker ) ;
for ( i = zs_size_classes - 1 ; i > = 0 ; i - - ) {
class = pool - > size_class [ i ] ;
if ( ! class )
continue ;
if ( class - > index ! = i )
continue ;
pages_to_free + = zs_can_compact ( class ) ;
}
return pages_to_free ;
}
static void zs_unregister_shrinker ( struct zs_pool * pool )
{
if ( pool - > shrinker_enabled ) {
unregister_shrinker ( & pool - > shrinker ) ;
pool - > shrinker_enabled = false ;
}
}
static int zs_register_shrinker ( struct zs_pool * pool )
{
pool - > shrinker . scan_objects = zs_shrinker_scan ;
pool - > shrinker . count_objects = zs_shrinker_count ;
pool - > shrinker . batch = 0 ;
pool - > shrinker . seeks = DEFAULT_SEEKS ;
return register_shrinker ( & pool - > shrinker ) ;
}
2012-05-03 10:40:40 +04:00
/**
2014-12-19 03:17:40 +03:00
* zs_create_pool - Creates an allocation pool to work from .
* @ flags : allocation flags used to allocate pool metadata
2012-07-03 01:15:51 +04:00
*
2014-12-19 03:17:40 +03:00
* This function must be called before anything when using
* the zsmalloc allocator .
2012-07-03 01:15:51 +04:00
*
2014-12-19 03:17:40 +03:00
* On success , a pointer to the newly created pool is returned ,
* otherwise NULL .
2013-05-20 23:18:14 +04:00
*/
2016-05-21 02:59:48 +03:00
struct zs_pool * zs_create_pool ( const char * name )
2012-01-10 02:51:56 +04:00
{
2014-12-19 03:17:40 +03:00
int i ;
struct zs_pool * pool ;
struct size_class * prev_class = NULL ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
pool = kzalloc ( sizeof ( * pool ) , GFP_KERNEL ) ;
if ( ! pool )
return NULL ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
pool - > size_class = kcalloc ( zs_size_classes , sizeof ( struct size_class * ) ,
GFP_KERNEL ) ;
if ( ! pool - > size_class ) {
kfree ( pool ) ;
return NULL ;
}
2012-01-10 02:51:56 +04:00
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
pool - > name = kstrdup ( name , GFP_KERNEL ) ;
if ( ! pool - > name )
goto err ;
2016-07-27 01:23:23 +03:00
if ( create_cache ( pool ) )
zsmalloc: decouple handle and object
Recently, we started to use zram heavily and some of issues
popped.
1) external fragmentation
I got a report from Juneho Choi that fork failed although there are plenty
of free pages in the system. His investigation revealed zram is one of
the culprit to make heavy fragmentation so there was no more contiguous
16K page for pgd to fork in the ARM.
2) non-movable pages
Other problem of zram now is that inherently, user want to use zram as
swap in small memory system so they use zRAM with CMA to use memory
efficiently. However, unfortunately, it doesn't work well because zRAM
cannot use CMA's movable pages unless it doesn't support compaction. I
got several reports about that OOM happened with zram although there are
lots of swap space and free space in CMA area.
3) internal fragmentation
zRAM has started support memory limitation feature to limit memory usage
and I sent a patchset(https://lkml.org/lkml/2014/9/21/148) for VM to be
harmonized with zram-swap to stop anonymous page reclaim if zram consumed
memory up to the limit although there are free space on the swap. One
problem for that direction is zram has no way to know any hole in memory
space zsmalloc allocated by internal fragmentation so zram would regard
swap is full although there are free space in zsmalloc. For solving the
issue, zram want to trigger compaction of zsmalloc before it decides full
or not.
This patchset is first step to support above issues. For that, it adds
indirect layer between handle and object location and supports manual
compaction to solve 3th problem first of all.
After this patchset got merged, next step is to make VM aware of zsmalloc
compaction so that generic compaction will move zsmalloced-pages
automatically in runtime.
In my imaginary experiment(ie, high compress ratio data with heavy swap
in/out on 8G zram-swap), data is as follows,
Before =
zram allocated object : 60212066 bytes
zram total used: 140103680 bytes
ratio: 42.98 percent
MemFree: 840192 kB
Compaction
After =
frag ratio after compaction
zram allocated object : 60212066 bytes
zram total used: 76185600 bytes
ratio: 79.03 percent
MemFree: 901932 kB
Juneho reported below in his real platform with small aging.
So, I think the benefit would be bigger in real aging system
for a long time.
- frag_ratio increased 3% (ie, higher is better)
- memfree increased about 6MB
- In buddy info, Normal 2^3: 4, 2^2: 1: 2^1 increased, Highmem: 2^1 21 increased
frag ratio after swap fragment
used : 156677 kbytes
total: 166092 kbytes
frag_ratio : 94
meminfo before compaction
MemFree: 83724 kB
Node 0, zone Normal 13642 1364 57 10 61 17 9 5 4 0 0
Node 0, zone HighMem 425 29 1 0 0 0 0 0 0 0 0
num_migrated : 23630
compaction done
frag ratio after compaction
used : 156673 kbytes
total: 160564 kbytes
frag_ratio : 97
meminfo after compaction
MemFree: 89060 kB
Node 0, zone Normal 14076 1544 67 14 61 17 9 5 4 0 0
Node 0, zone HighMem 863 50 1 0 0 0 0 0 0 0 0
This patchset adds more logics(about 480 lines) in zsmalloc but when I
tested heavy swapin/out program, the regression for swapin/out speed is
marginal because most of overheads were caused by compress/decompress and
other MM reclaim stuff.
This patch (of 7):
Currently, handle of zsmalloc encodes object's location directly so it
makes support of migration hard.
This patch decouples handle and object via adding indirect layer. For
that, it allocates handle dynamically and returns it to user. The handle
is the address allocated by slab allocation so it's unique and we could
keep object's location in the memory space allocated for handle.
With it, we can change object's position without changing handle itself.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 02:15:23 +03:00
goto err ;
2012-07-18 20:55:55 +04:00
/*
2014-12-19 03:17:40 +03:00
* Iterate reversly , because , size of size_class that we want to use
* for merging should be larger or equal to current size .
2012-07-18 20:55:55 +04:00
*/
2014-12-19 03:17:40 +03:00
for ( i = zs_size_classes - 1 ; i > = 0 ; i - - ) {
int size ;
int pages_per_zspage ;
struct size_class * class ;
2016-07-27 01:23:23 +03:00
int fullness = 0 ;
2012-07-18 20:55:55 +04:00
2014-12-19 03:17:40 +03:00
size = ZS_MIN_ALLOC_SIZE + i * ZS_SIZE_CLASS_DELTA ;
if ( size > ZS_MAX_ALLOC_SIZE )
size = ZS_MAX_ALLOC_SIZE ;
pages_per_zspage = get_pages_per_zspage ( size ) ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
/*
* size_class is used for normal zsmalloc operation such
* as alloc / free for that size . Although it is natural that we
* have one size_class for each size , there is a chance that we
* can get more memory utilization if we use one size_class for
* many different sizes whose size_class have same
* characteristics . So , we makes size_class point to
* previous size_class if possible .
*/
if ( prev_class ) {
if ( can_merge ( prev_class , size , pages_per_zspage ) ) {
pool - > size_class [ i ] = prev_class ;
continue ;
}
}
class = kzalloc ( sizeof ( struct size_class ) , GFP_KERNEL ) ;
if ( ! class )
goto err ;
class - > size = size ;
class - > index = i ;
class - > pages_per_zspage = pages_per_zspage ;
2016-07-27 01:23:11 +03:00
class - > objs_per_zspage = class - > pages_per_zspage *
PAGE_SIZE / class - > size ;
if ( pages_per_zspage = = 1 & & class - > objs_per_zspage = = 1 )
2015-04-16 02:15:39 +03:00
class - > huge = true ;
2014-12-19 03:17:40 +03:00
spin_lock_init ( & class - > lock ) ;
pool - > size_class [ i ] = class ;
2016-07-27 01:23:23 +03:00
for ( fullness = ZS_ALMOST_FULL ; fullness < = ZS_ALMOST_EMPTY ;
fullness + + )
INIT_LIST_HEAD ( & class - > fullness_list [ fullness ] ) ;
2014-12-19 03:17:40 +03:00
prev_class = class ;
2012-01-10 02:51:56 +04:00
}
2016-05-21 02:59:56 +03:00
/* debug only, don't abort if it fails */
zs_pool_stat_create ( pool , name ) ;
2015-02-13 02:00:54 +03:00
2015-09-09 01:04:41 +03:00
/*
* Not critical , we still can use the pool
* and user can trigger compaction manually .
*/
if ( zs_register_shrinker ( pool ) = = 0 )
pool - > shrinker_enabled = true ;
2014-12-19 03:17:40 +03:00
return pool ;
err :
zs_destroy_pool ( pool ) ;
return NULL ;
2012-01-10 02:51:56 +04:00
}
2014-12-19 03:17:40 +03:00
EXPORT_SYMBOL_GPL ( zs_create_pool ) ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
void zs_destroy_pool ( struct zs_pool * pool )
2012-01-10 02:51:56 +04:00
{
2014-12-19 03:17:40 +03:00
int i ;
2012-01-10 02:51:56 +04:00
2015-09-09 01:04:41 +03:00
zs_unregister_shrinker ( pool ) ;
2015-02-13 02:00:54 +03:00
zs_pool_stat_destroy ( pool ) ;
2014-12-19 03:17:40 +03:00
for ( i = 0 ; i < zs_size_classes ; i + + ) {
int fg ;
struct size_class * class = pool - > size_class [ i ] ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
if ( ! class )
continue ;
2012-01-10 02:51:56 +04:00
2014-12-19 03:17:40 +03:00
if ( class - > index ! = i )
continue ;
2012-01-10 02:51:56 +04:00
2016-07-27 01:23:23 +03:00
for ( fg = ZS_ALMOST_FULL ; fg < = ZS_ALMOST_EMPTY ; fg + + ) {
if ( ! list_empty ( & class - > fullness_list [ fg ] ) ) {
2014-12-19 03:17:40 +03:00
pr_info ( " Freeing non-empty class with size %db, fullness group %d \n " ,
class - > size , fg ) ;
}
}
kfree ( class ) ;
}
2012-07-18 20:55:56 +04:00
2016-07-27 01:23:23 +03:00
destroy_cache ( pool ) ;
2014-12-19 03:17:40 +03:00
kfree ( pool - > size_class ) ;
2015-02-13 02:00:54 +03:00
kfree ( pool - > name ) ;
2014-12-19 03:17:40 +03:00
kfree ( pool ) ;
}
EXPORT_SYMBOL_GPL ( zs_destroy_pool ) ;
2012-07-03 01:15:52 +04:00
2014-12-19 03:17:40 +03:00
static int __init zs_init ( void )
{
int ret = zs_register_cpu_notifier ( ) ;
2015-02-13 02:00:54 +03:00
if ( ret )
goto notifier_fail ;
2014-12-19 03:17:40 +03:00
init_zs_size_classes ( ) ;
# ifdef CONFIG_ZPOOL
zpool_register_driver ( & zs_zpool_driver ) ;
# endif
2015-02-13 02:00:54 +03:00
2016-05-27 01:16:27 +03:00
zs_stat_init ( ) ;
2014-12-19 03:17:40 +03:00
return 0 ;
2015-02-13 02:00:54 +03:00
notifier_fail :
zs_unregister_cpu_notifier ( ) ;
return ret ;
2012-01-10 02:51:56 +04:00
}
2014-12-19 03:17:40 +03:00
static void __exit zs_exit ( void )
2012-01-10 02:51:56 +04:00
{
2014-12-19 03:17:40 +03:00
# ifdef CONFIG_ZPOOL
zpool_unregister_driver ( & zs_zpool_driver ) ;
# endif
zs_unregister_cpu_notifier ( ) ;
2015-02-13 02:00:54 +03:00
zs_stat_exit ( ) ;
2012-01-10 02:51:56 +04:00
}
2012-06-20 05:31:11 +04:00
module_init ( zs_init ) ;
module_exit ( zs_exit ) ;
MODULE_LICENSE ( " Dual BSD/GPL " ) ;
MODULE_AUTHOR ( " Nitin Gupta <ngupta@vflare.org> " ) ;