linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Streetman <ddstreet@ieee.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Nitin Gupta <ngupta@vflare.org>,
	Seth Jennings <sjennings@variantweb.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Streetman <ddstreet@ieee.org>
Subject: [PATCH 05/10] zsmalloc: add atomic index to find zspage to reclaim
Date: Thu, 11 Sep 2014 16:53:56 -0400	[thread overview]
Message-ID: <1410468841-320-6-git-send-email-ddstreet@ieee.org> (raw)
In-Reply-To: <1410468841-320-1-git-send-email-ddstreet@ieee.org>

Add an atomic index that allows multiple threads to concurrently and
sequentially iterate through the zspages in all classes and fullness
groups.  Add a function find_next_lru_class_fg() to find the next class
fullness group to check for a zspage.  Add a function find_lru_zspage()
which calls find_next_lru_class_fg() until a fullness group with an
available zspage is found.  This is required to implement zsmalloc pool
shrinking, which needs to be able to find a zspage to reclaim.

Since zsmalloc categorizes its zspages in arrays of fullness groups, which
are themselves inside arrays of classes, there is no (simple) way to
determine the LRU order of all a zsmalloc pool's zspages.  But to implement
shrinking, there must be some way to select the zspage to reclaim.  This
can't use a simple iteration through all classes, since any failure to
reclaim a zspage would result in any following reclaims to attempt to
reclaim the same zspage, which would likely result in repeated failures
to shrink the pool.

Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Minchan Kim <minchan@kernel.org>
---
 mm/zsmalloc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index cff8935..a2e417b 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -242,6 +242,16 @@ struct mapping_area {
 	enum zs_mapmode vm_mm; /* mapping mode */
 };
 
+/* atomic counter indicating which class/fg to reclaim from */
+static atomic_t lru_class_fg;
+/* specific order of fg we want to reclaim from */
+static enum fullness_group lru_fg[] = {
+	ZS_ALMOST_EMPTY,
+	ZS_ALMOST_FULL,
+	ZS_FULL
+};
+#define _ZS_NR_LRU_CLASS_FG (ZS_SIZE_CLASSES * ARRAY_SIZE(lru_fg))
+
 /* zpool driver */
 
 #ifdef CONFIG_ZPOOL
@@ -752,6 +762,64 @@ static struct page *find_available_zspage(struct size_class *class)
 	return page;
 }
 
+/* this simply iterates atomically through all classes,
+ * using a specific fullness group.  At the end, it starts
+ * over using the next fullness group, and so on.  The
+ * fullness groups are used in a specific order, from
+ * least to most full.
+ */
+static void find_next_lru_class_fg(struct zs_pool *pool,
+			struct size_class **class, enum fullness_group *fg)
+{
+	int i = atomic_inc_return(&lru_class_fg);
+
+	if (i >= _ZS_NR_LRU_CLASS_FG) {
+		int orig = i;
+
+		i %= _ZS_NR_LRU_CLASS_FG;
+		/* only need to try once, since if we don't
+		 * succeed whoever changed it will also try
+		 * and eventually someone will reset it
+		 */
+		atomic_cmpxchg(&lru_class_fg, orig, i);
+	}
+	*class = &pool->size_class[i % ZS_SIZE_CLASSES];
+	*fg = lru_fg[i / ZS_SIZE_CLASSES];
+}
+
+/*
+ * This attempts to find the LRU zspage, but that's not really possible
+ * because zspages are not contained in a single LRU list, they're
+ * contained inside fullness groups which are themselves contained
+ * inside classes.  So this simply iterates through the classes and
+ * fullness groups to find the next non-empty fullness group, and
+ * uses the LRU zspage there.
+ *
+ * On success, the zspage is returned with its class locked.
+ * On failure, NULL is returned.
+ */
+static struct page *find_lru_zspage(struct zs_pool *pool)
+{
+	struct size_class *class;
+	struct page *page;
+	enum fullness_group fg;
+	int tries = 0;
+
+	while (tries++ < _ZS_NR_LRU_CLASS_FG) {
+		find_next_lru_class_fg(pool, &class, &fg);
+
+		spin_lock(&class->lock);
+
+		page = class->fullness_list[fg];
+		if (page)
+			return list_prev_entry(page, lru);
+
+		spin_unlock(&class->lock);
+	}
+
+	return NULL;
+}
+
 #ifdef CONFIG_PGTABLE_MAPPING
 static inline int __zs_cpu_up(struct mapping_area *area)
 {
-- 
1.8.3.1


  parent reply	other threads:[~2014-09-11 20:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 20:53 [PATCH 00/10] implement zsmalloc shrinking Dan Streetman
2014-09-11 20:53 ` [PATCH 01/10] zsmalloc: fix init_zspage free obj linking Dan Streetman
2014-09-12  3:16   ` Seth Jennings
2014-09-12  4:59   ` Minchan Kim
2014-09-12 16:43     ` Dan Streetman
2014-09-14 23:24       ` Minchan Kim
2014-09-15 20:58         ` [PATCH] zsmalloc: simplify " Dan Streetman
2014-09-16  2:41           ` Minchan Kim
2014-09-11 20:53 ` [PATCH 02/10] zsmalloc: add fullness group list for ZS_FULL zspages Dan Streetman
2014-09-11 20:53 ` [PATCH 03/10] zsmalloc: always update lru ordering of each zspage Dan Streetman
2014-09-12  3:20   ` Seth Jennings
2014-09-11 20:53 ` [PATCH 04/10] zsmalloc: move zspage obj freeing to separate function Dan Streetman
2014-09-11 20:53 ` Dan Streetman [this message]
2014-09-11 20:53 ` [PATCH 06/10] zsmalloc: add zs_ops to zs_pool Dan Streetman
2014-09-11 20:53 ` [PATCH 07/10] zsmalloc: add obj_handle_is_free() Dan Streetman
2014-09-11 20:53 ` [PATCH 08/10] zsmalloc: add reclaim_zspage() Dan Streetman
2014-09-11 20:54 ` [PATCH 09/10] zsmalloc: add zs_shrink() Dan Streetman
2014-09-11 20:54 ` [PATCH 10/10] zsmalloc: implement zs_zpool_shrink() with zs_shrink() Dan Streetman
2014-09-12  3:14 ` [PATCH 00/10] implement zsmalloc shrinking Seth Jennings
2014-09-12  5:46 ` Minchan Kim
2014-09-12 17:05   ` Dan Streetman
2014-09-15  0:00     ` Minchan Kim
2014-09-15 14:29       ` Dan Streetman

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=1410468841-320-6-git-send-email-ddstreet@ieee.org \
    --to=ddstreet@ieee.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sjennings@variantweb.net \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).