From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> To: Minchan Kim <minchan@kernel.org>, Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Subject: [PATCHv2 1/2] zsmalloc: introduce zs_huge_object() function Date: Sat, 10 Feb 2018 17:23:21 +0900 [thread overview] Message-ID: <20180210082321.17798-1-sergey.senozhatsky@gmail.com> (raw) In-Reply-To: <20180207092919.19696-2-sergey.senozhatsky@gmail.com> Not every object can be share its zspage with other objects, e.g. when the object is as big as zspage or nearly as big a zspage. For such objects zsmalloc has a so called huge class - every object which belongs to huge class consumes the entire zspage (which consists of a physical page). On x86_64, PAGE_SHIFT 12 box, the first non-huge class size is 3264, so starting down from size 3264, objects can share page(-s) and thus minimize memory wastage. ZRAM, however, has its own statically defined watermark for huge objects - "3 * PAGE_SIZE / 4 = 3072", and forcibly stores every object larger than this watermark (3072) as a PAGE_SIZE object, in other words, to a huge class, while zsmalloc can keep some of those objects in non-huge classes. This results in increased memory consumption. zsmalloc knows better if the object is huge or not. Introduce zs_huge_object() function which tells if the given object can be stored in one of non-huge classes or not. This will let us to drop ZRAM's huge object watermark and fully rely on zsmalloc when we decide if the object is huge. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> --- include/linux/zsmalloc.h | 2 ++ mm/zsmalloc.c | 26 ++++++++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h index 57a8e98f2708..9a1baf673cc1 100644 --- a/include/linux/zsmalloc.h +++ b/include/linux/zsmalloc.h @@ -47,6 +47,8 @@ void zs_destroy_pool(struct zs_pool *pool); unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t flags); void zs_free(struct zs_pool *pool, unsigned long obj); +bool zs_huge_object(size_t sz); + void *zs_map_object(struct zs_pool *pool, unsigned long handle, enum zs_mapmode mm); void zs_unmap_object(struct zs_pool *pool, unsigned long handle); diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index c3013505c305..922180183ca3 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -192,6 +192,7 @@ static struct vfsmount *zsmalloc_mnt; * (see: fix_fullness_group()) */ static const int fullness_threshold_frac = 4; +static size_t zs_huge_class_size; struct size_class { spinlock_t lock; @@ -1417,6 +1418,28 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long handle) } EXPORT_SYMBOL_GPL(zs_unmap_object); +/** + * zs_huge_object() - Test if a compressed object's size is too big for normal + * zspool classes and it shall be stored in a huge class. + * @sz: Size of the compressed object (in bytes). + * + * The function checks if the object's size falls into huge_class + * area. We must take handle size into account and test the actual + * size we are going to use, because zs_malloc() unconditionally + * adds %ZS_HANDLE_SIZE before it performs %size_class lookup. + * + * Context: Any context. + * + * Return: + * * true - The object's size is too big, it will be stored in a huge class. + * * false - The object will be store in normal zspool classes. + */ +bool zs_huge_object(size_t sz) +{ + return sz + ZS_HANDLE_SIZE >= zs_huge_class_size; +} +EXPORT_SYMBOL_GPL(zs_huge_object); + static unsigned long obj_malloc(struct size_class *class, struct zspage *zspage, unsigned long handle) { @@ -2404,6 +2427,9 @@ struct zs_pool *zs_create_pool(const char *name) INIT_LIST_HEAD(&class->fullness_list[fullness]); prev_class = class; + if (pages_per_zspage == 1 && objs_per_zspage == 1 + && !zs_huge_class_size) + zs_huge_class_size = size; } /* debug only, don't abort if it fails */ -- 2.16.1
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> To: Minchan Kim <minchan@kernel.org>, Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Subject: [PATCHv2 1/2] zsmalloc: introduce zs_huge_object() function Date: Sat, 10 Feb 2018 17:23:21 +0900 [thread overview] Message-ID: <20180210082321.17798-1-sergey.senozhatsky@gmail.com> (raw) In-Reply-To: <20180207092919.19696-2-sergey.senozhatsky@gmail.com> Not every object can be share its zspage with other objects, e.g. when the object is as big as zspage or nearly as big a zspage. For such objects zsmalloc has a so called huge class - every object which belongs to huge class consumes the entire zspage (which consists of a physical page). On x86_64, PAGE_SHIFT 12 box, the first non-huge class size is 3264, so starting down from size 3264, objects can share page(-s) and thus minimize memory wastage. ZRAM, however, has its own statically defined watermark for huge objects - "3 * PAGE_SIZE / 4 = 3072", and forcibly stores every object larger than this watermark (3072) as a PAGE_SIZE object, in other words, to a huge class, while zsmalloc can keep some of those objects in non-huge classes. This results in increased memory consumption. zsmalloc knows better if the object is huge or not. Introduce zs_huge_object() function which tells if the given object can be stored in one of non-huge classes or not. This will let us to drop ZRAM's huge object watermark and fully rely on zsmalloc when we decide if the object is huge. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> --- include/linux/zsmalloc.h | 2 ++ mm/zsmalloc.c | 26 ++++++++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h index 57a8e98f2708..9a1baf673cc1 100644 --- a/include/linux/zsmalloc.h +++ b/include/linux/zsmalloc.h @@ -47,6 +47,8 @@ void zs_destroy_pool(struct zs_pool *pool); unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t flags); void zs_free(struct zs_pool *pool, unsigned long obj); +bool zs_huge_object(size_t sz); + void *zs_map_object(struct zs_pool *pool, unsigned long handle, enum zs_mapmode mm); void zs_unmap_object(struct zs_pool *pool, unsigned long handle); diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index c3013505c305..922180183ca3 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -192,6 +192,7 @@ static struct vfsmount *zsmalloc_mnt; * (see: fix_fullness_group()) */ static const int fullness_threshold_frac = 4; +static size_t zs_huge_class_size; struct size_class { spinlock_t lock; @@ -1417,6 +1418,28 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long handle) } EXPORT_SYMBOL_GPL(zs_unmap_object); +/** + * zs_huge_object() - Test if a compressed object's size is too big for normal + * zspool classes and it shall be stored in a huge class. + * @sz: Size of the compressed object (in bytes). + * + * The function checks if the object's size falls into huge_class + * area. We must take handle size into account and test the actual + * size we are going to use, because zs_malloc() unconditionally + * adds %ZS_HANDLE_SIZE before it performs %size_class lookup. + * + * Context: Any context. + * + * Return: + * * true - The object's size is too big, it will be stored in a huge class. + * * false - The object will be store in normal zspool classes. + */ +bool zs_huge_object(size_t sz) +{ + return sz + ZS_HANDLE_SIZE >= zs_huge_class_size; +} +EXPORT_SYMBOL_GPL(zs_huge_object); + static unsigned long obj_malloc(struct size_class *class, struct zspage *zspage, unsigned long handle) { @@ -2404,6 +2427,9 @@ struct zs_pool *zs_create_pool(const char *name) INIT_LIST_HEAD(&class->fullness_list[fullness]); prev_class = class; + if (pages_per_zspage == 1 && objs_per_zspage == 1 + && !zs_huge_class_size) + zs_huge_class_size = size; } /* debug only, don't abort if it fails */ -- 2.16.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-10 8:23 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-07 9:29 [PATCH 0/2] zsmalloc/zram: drop zram's max_zpage_size Sergey Senozhatsky 2018-02-07 9:29 ` Sergey Senozhatsky 2018-02-07 9:29 ` [PATCH 1/2] zsmalloc: introduce zs_huge_object() function Sergey Senozhatsky 2018-02-07 9:29 ` Sergey Senozhatsky 2018-02-08 16:30 ` Mike Rapoport 2018-02-08 16:30 ` Mike Rapoport 2018-02-09 2:55 ` Sergey Senozhatsky 2018-02-09 2:55 ` Sergey Senozhatsky 2018-02-09 4:10 ` Matthew Wilcox 2018-02-09 4:10 ` Matthew Wilcox 2018-02-09 5:04 ` Sergey Senozhatsky 2018-02-09 5:04 ` Sergey Senozhatsky 2018-02-09 5:36 ` Sergey Senozhatsky 2018-02-09 5:36 ` Sergey Senozhatsky 2018-02-09 5:48 ` Sergey Senozhatsky 2018-02-09 5:48 ` Sergey Senozhatsky 2018-02-09 11:11 ` Mike Rapoport 2018-02-09 11:11 ` Mike Rapoport 2018-02-09 12:34 ` Sergey Senozhatsky 2018-02-09 12:34 ` Sergey Senozhatsky 2018-02-10 8:23 ` Sergey Senozhatsky [this message] 2018-02-10 8:23 ` [PATCHv2 " Sergey Senozhatsky 2018-02-11 7:05 ` Mike Rapoport 2018-02-11 7:05 ` Mike Rapoport 2018-02-14 5:52 ` Sergey Senozhatsky 2018-02-14 5:52 ` Sergey Senozhatsky 2018-02-14 5:57 ` [PATCHv3 " Sergey Senozhatsky 2018-02-14 5:57 ` Sergey Senozhatsky 2018-02-20 1:24 ` Minchan Kim 2018-02-20 1:24 ` Minchan Kim 2018-02-26 5:49 ` Sergey Senozhatsky 2018-02-26 5:49 ` Sergey Senozhatsky 2018-02-26 5:58 ` Minchan Kim 2018-02-26 5:58 ` Minchan Kim 2018-02-26 6:50 ` Sergey Senozhatsky 2018-02-26 6:50 ` Sergey Senozhatsky 2018-02-26 7:46 ` Minchan Kim 2018-02-26 7:46 ` Minchan Kim 2018-02-26 8:12 ` Sergey Senozhatsky 2018-02-26 8:12 ` Sergey Senozhatsky 2018-02-07 9:29 ` [PATCH 2/2] zram: drop max_zpage_size and use zs_huge_object() Sergey Senozhatsky 2018-02-07 9:29 ` Sergey Senozhatsky
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180210082321.17798-1-sergey.senozhatsky@gmail.com \ --to=sergey.senozhatsky@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan@kernel.org \ --cc=rppt@linux.vnet.ibm.com \ --cc=sergey.senozhatsky.work@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.