diff for duplicates of <20150317011258.GA11994@blaptop> diff --git a/a/1.txt b/N1/1.txt index 040af1d..36b53fe 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -44,3 +44,154 @@ On Wed, Mar 04, 2015 at 04:56:10PM -0800, Andrew Morton wrote: > Documentation/vm/zsmalloc.txt looks good. Here it goes. + +>From cb5ac24125c14467d1a5b6fbb92757d5517b0300 Mon Sep 17 00:00:00 2001 +From: Minchan Kim <minchan@kernel.org> +Date: Tue, 17 Mar 2015 10:02:07 +0900 +Subject: [PATCH] zsmalloc: zsmalloc documentation + +This patch creates zsmalloc doc which explains design concept +and stat information. + +Signed-off-by: Minchan Kim <minchan@kernel.org> +--- + Documentation/vm/zsmalloc.txt | 70 +++++++++++++++++++++++++++++++++++++++++++ + MAINTAINERS | 1 + + mm/zsmalloc.c | 29 ------------------ + 3 files changed, 71 insertions(+), 29 deletions(-) + create mode 100644 Documentation/vm/zsmalloc.txt + +diff --git a/Documentation/vm/zsmalloc.txt b/Documentation/vm/zsmalloc.txt +new file mode 100644 +index 000000000000..64ed63c4f69d +--- /dev/null ++++ b/Documentation/vm/zsmalloc.txt +@@ -0,0 +1,70 @@ ++zsmalloc ++-------- ++ ++This allocator is designed for use with zram. Thus, the allocator is ++supposed to work well under low memory conditions. In particular, it ++never attempts higher order page allocation which is very likely to ++fail under memory pressure. On the other hand, if we just use single ++(0-order) pages, it would suffer from very high fragmentation -- ++any object of size PAGE_SIZE/2 or larger would occupy an entire page. ++This was one of the major issues with its predecessor (xvmalloc). ++ ++To overcome these issues, zsmalloc allocates a bunch of 0-order pages ++and links them together using various 'struct page' fields. These linked ++pages act as a single higher-order page i.e. an object can span 0-order ++page boundaries. The code refers to these linked pages as a single entity ++called zspage. ++ ++For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE ++since this satisfies the requirements of all its current users (in the ++worst case, page is incompressible and is thus stored "as-is" i.e. in ++uncompressed form). For allocation requests larger than this size, failure ++is returned (see zs_malloc). ++ ++Additionally, zs_malloc() does not return a dereferenceable pointer. ++Instead, it returns an opaque handle (unsigned long) which encodes actual ++location of the allocated object. The reason for this indirection is that ++zsmalloc does not keep zspages permanently mapped since that would cause ++issues on 32-bit systems where the VA region for kernel space mappings ++is very small. So, before using the allocating memory, the object has to ++be mapped using zs_map_object() to get a usable pointer and subsequently ++unmapped using zs_unmap_object(). ++ ++stat ++---- ++ ++With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via ++/sys/kernel/debug/zsmalloc/<user name>. Here is a sample of stat output: ++ ++# cat /sys/kernel/debug/zsmalloc/zram0/classes ++ ++ class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage ++ .. ++ .. ++ 9 176 0 1 186 129 8 4 ++ 10 192 1 0 2880 2872 135 3 ++ 11 208 0 1 819 795 42 2 ++ 12 224 0 1 219 159 12 4 ++ .. ++ .. ++ ++ ++class: index ++size: object size zspage stores ++almost_empty: the number of ZS_ALMOST_EMPTY zspages(see below) ++almost_full: the number of ZS_ALMOST_FULL zspages(see below) ++obj_allocated: the number of objects allocated ++obj_used: the number of objects allocated to the user ++pages_used: the number of pages allocated for the class ++pages_per_zspage: the number of 0-order pages to make a zspage ++ ++We assign a zspage to ZS_ALMOST_EMPTY fullness group when: ++ n <= N / f, where ++n = number of allocated objects ++N = total number of objects zspage can store ++f = fullness_threshold_frac(ie, 4 at the moment) ++ ++Similarly, we assign zspage to: ++ ZS_ALMOST_FULL when n > N / f ++ ZS_EMPTY when n == 0 ++ ZS_FULL when n == N +diff --git a/MAINTAINERS b/MAINTAINERS +index b60d478770e9..560168c6530a 100644 +--- a/MAINTAINERS ++++ b/MAINTAINERS +@@ -10945,6 +10945,7 @@ L: linux-mm@kvack.org + S: Maintained + F: mm/zsmalloc.c + F: include/linux/zsmalloc.h ++F: Documentation/vm/zsmalloc.txt + + ZSWAP COMPRESSED SWAP CACHING + M: Seth Jennings <sjennings@variantweb.net> +diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c +index 461243e14d3e..1833fc9e09cb 100644 +--- a/mm/zsmalloc.c ++++ b/mm/zsmalloc.c +@@ -12,35 +12,6 @@ + */ + + /* +- * This allocator is designed for use with zram. Thus, the allocator is +- * supposed to work well under low memory conditions. In particular, it +- * never attempts higher order page allocation which is very likely to +- * fail under memory pressure. On the other hand, if we just use single +- * (0-order) pages, it would suffer from very high fragmentation -- +- * any object of size PAGE_SIZE/2 or larger would occupy an entire page. +- * This was one of the major issues with its predecessor (xvmalloc). +- * +- * To overcome these issues, zsmalloc allocates a bunch of 0-order pages +- * and links them together using various 'struct page' fields. These linked +- * pages act as a single higher-order page i.e. an object can span 0-order +- * page boundaries. The code refers to these linked pages as a single entity +- * called zspage. +- * +- * For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE +- * since this satisfies the requirements of all its current users (in the +- * worst case, page is incompressible and is thus stored "as-is" i.e. in +- * uncompressed form). For allocation requests larger than this size, failure +- * is returned (see zs_malloc). +- * +- * Additionally, zs_malloc() does not return a dereferenceable pointer. +- * Instead, it returns an opaque handle (unsigned long) which encodes actual +- * location of the allocated object. The reason for this indirection is that +- * zsmalloc does not keep zspages permanently mapped since that would cause +- * issues on 32-bit systems where the VA region for kernel space mappings +- * is very small. So, before using the allocating memory, the object has to +- * be mapped using zs_map_object() to get a usable pointer and subsequently +- * unmapped using zs_unmap_object(). +- * + * Following is how we use various fields and flags of underlying + * struct page(s) to form a zspage. + * +-- +1.9.1 + +-- +Kind regards, +Minchan Kim diff --git a/a/content_digest b/N1/content_digest index 2497e92..148686e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -61,6 +61,157 @@ "> \n" "> Documentation/vm/zsmalloc.txt looks good.\n" "\n" - Here it goes. + "Here it goes.\n" + "\n" + ">From cb5ac24125c14467d1a5b6fbb92757d5517b0300 Mon Sep 17 00:00:00 2001\n" + "From: Minchan Kim <minchan@kernel.org>\n" + "Date: Tue, 17 Mar 2015 10:02:07 +0900\n" + "Subject: [PATCH] zsmalloc: zsmalloc documentation\n" + "\n" + "This patch creates zsmalloc doc which explains design concept\n" + "and stat information.\n" + "\n" + "Signed-off-by: Minchan Kim <minchan@kernel.org>\n" + "---\n" + " Documentation/vm/zsmalloc.txt | 70 +++++++++++++++++++++++++++++++++++++++++++\n" + " MAINTAINERS | 1 +\n" + " mm/zsmalloc.c | 29 ------------------\n" + " 3 files changed, 71 insertions(+), 29 deletions(-)\n" + " create mode 100644 Documentation/vm/zsmalloc.txt\n" + "\n" + "diff --git a/Documentation/vm/zsmalloc.txt b/Documentation/vm/zsmalloc.txt\n" + "new file mode 100644\n" + "index 000000000000..64ed63c4f69d\n" + "--- /dev/null\n" + "+++ b/Documentation/vm/zsmalloc.txt\n" + "@@ -0,0 +1,70 @@\n" + "+zsmalloc\n" + "+--------\n" + "+\n" + "+This allocator is designed for use with zram. Thus, the allocator is\n" + "+supposed to work well under low memory conditions. In particular, it\n" + "+never attempts higher order page allocation which is very likely to\n" + "+fail under memory pressure. On the other hand, if we just use single\n" + "+(0-order) pages, it would suffer from very high fragmentation --\n" + "+any object of size PAGE_SIZE/2 or larger would occupy an entire page.\n" + "+This was one of the major issues with its predecessor (xvmalloc).\n" + "+\n" + "+To overcome these issues, zsmalloc allocates a bunch of 0-order pages\n" + "+and links them together using various 'struct page' fields. These linked\n" + "+pages act as a single higher-order page i.e. an object can span 0-order\n" + "+page boundaries. The code refers to these linked pages as a single entity\n" + "+called zspage.\n" + "+\n" + "+For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE\n" + "+since this satisfies the requirements of all its current users (in the\n" + "+worst case, page is incompressible and is thus stored \"as-is\" i.e. in\n" + "+uncompressed form). For allocation requests larger than this size, failure\n" + "+is returned (see zs_malloc).\n" + "+\n" + "+Additionally, zs_malloc() does not return a dereferenceable pointer.\n" + "+Instead, it returns an opaque handle (unsigned long) which encodes actual\n" + "+location of the allocated object. The reason for this indirection is that\n" + "+zsmalloc does not keep zspages permanently mapped since that would cause\n" + "+issues on 32-bit systems where the VA region for kernel space mappings\n" + "+is very small. So, before using the allocating memory, the object has to\n" + "+be mapped using zs_map_object() to get a usable pointer and subsequently\n" + "+unmapped using zs_unmap_object().\n" + "+\n" + "+stat\n" + "+----\n" + "+\n" + "+With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via\n" + "+/sys/kernel/debug/zsmalloc/<user name>. Here is a sample of stat output:\n" + "+\n" + "+# cat /sys/kernel/debug/zsmalloc/zram0/classes\n" + "+\n" + "+ class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage\n" + "+ ..\n" + "+ ..\n" + "+ 9 176 0 1 186 129 8 4\n" + "+ 10 192 1 0 2880 2872 135 3\n" + "+ 11 208 0 1 819 795 42 2\n" + "+ 12 224 0 1 219 159 12 4\n" + "+ ..\n" + "+ ..\n" + "+\n" + "+\n" + "+class: index\n" + "+size: object size zspage stores\n" + "+almost_empty: the number of ZS_ALMOST_EMPTY zspages(see below)\n" + "+almost_full: the number of ZS_ALMOST_FULL zspages(see below)\n" + "+obj_allocated: the number of objects allocated\n" + "+obj_used: the number of objects allocated to the user\n" + "+pages_used: the number of pages allocated for the class\n" + "+pages_per_zspage: the number of 0-order pages to make a zspage\n" + "+\n" + "+We assign a zspage to ZS_ALMOST_EMPTY fullness group when:\n" + "+ n <= N / f, where\n" + "+n = number of allocated objects\n" + "+N = total number of objects zspage can store\n" + "+f = fullness_threshold_frac(ie, 4 at the moment)\n" + "+\n" + "+Similarly, we assign zspage to:\n" + "+ ZS_ALMOST_FULL when n > N / f\n" + "+ ZS_EMPTY when n == 0\n" + "+ ZS_FULL when n == N\n" + "diff --git a/MAINTAINERS b/MAINTAINERS\n" + "index b60d478770e9..560168c6530a 100644\n" + "--- a/MAINTAINERS\n" + "+++ b/MAINTAINERS\n" + "@@ -10945,6 +10945,7 @@ L:\tlinux-mm@kvack.org\n" + " S:\tMaintained\n" + " F:\tmm/zsmalloc.c\n" + " F:\tinclude/linux/zsmalloc.h\n" + "+F:\tDocumentation/vm/zsmalloc.txt\n" + " \n" + " ZSWAP COMPRESSED SWAP CACHING\n" + " M:\tSeth Jennings <sjennings@variantweb.net>\n" + "diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c\n" + "index 461243e14d3e..1833fc9e09cb 100644\n" + "--- a/mm/zsmalloc.c\n" + "+++ b/mm/zsmalloc.c\n" + "@@ -12,35 +12,6 @@\n" + " */\n" + " \n" + " /*\n" + "- * This allocator is designed for use with zram. Thus, the allocator is\n" + "- * supposed to work well under low memory conditions. In particular, it\n" + "- * never attempts higher order page allocation which is very likely to\n" + "- * fail under memory pressure. On the other hand, if we just use single\n" + "- * (0-order) pages, it would suffer from very high fragmentation --\n" + "- * any object of size PAGE_SIZE/2 or larger would occupy an entire page.\n" + "- * This was one of the major issues with its predecessor (xvmalloc).\n" + "- *\n" + "- * To overcome these issues, zsmalloc allocates a bunch of 0-order pages\n" + "- * and links them together using various 'struct page' fields. These linked\n" + "- * pages act as a single higher-order page i.e. an object can span 0-order\n" + "- * page boundaries. The code refers to these linked pages as a single entity\n" + "- * called zspage.\n" + "- *\n" + "- * For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE\n" + "- * since this satisfies the requirements of all its current users (in the\n" + "- * worst case, page is incompressible and is thus stored \"as-is\" i.e. in\n" + "- * uncompressed form). For allocation requests larger than this size, failure\n" + "- * is returned (see zs_malloc).\n" + "- *\n" + "- * Additionally, zs_malloc() does not return a dereferenceable pointer.\n" + "- * Instead, it returns an opaque handle (unsigned long) which encodes actual\n" + "- * location of the allocated object. The reason for this indirection is that\n" + "- * zsmalloc does not keep zspages permanently mapped since that would cause\n" + "- * issues on 32-bit systems where the VA region for kernel space mappings\n" + "- * is very small. So, before using the allocating memory, the object has to\n" + "- * be mapped using zs_map_object() to get a usable pointer and subsequently\n" + "- * unmapped using zs_unmap_object().\n" + "- *\n" + " * Following is how we use various fields and flags of underlying\n" + " * struct page(s) to form a zspage.\n" + " *\n" + "-- \n" + "1.9.1\n" + "\n" + "-- \n" + "Kind regards,\n" + Minchan Kim -0b47781241b54016b9e8a23666a38ef1faf15a5e8ba3a6607713026742a1ba19 +918acfbd7a9c8f55bc830396f813eda82c9f282d6e501da7d7e3a0f53d46aedc
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.