From: Chao Yu <chao2.yu@samsung.com>
To: sjennings@variantweb.net
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH] zbud: avoid accessing in last unused freelist
Date: Wed, 03 Sep 2014 13:54:09 +0800 [thread overview]
Message-ID: <000001cfc73b$9340d050$b9c270f0$@samsung.com> (raw)
For now, there are NCHUNKS of 64 freelists in zbud_pool, the last unbuddied[63]
freelist linked with all zbud pages which have free chunks of 63. Calculating
according to context of num_free_chunks(), our max chunk number of unbuddied
zbud page is 62, so none of zbud pages will be added/removed in last freelist,
but still we will try to find an unbuddied zbud page in the last unused
freelist, it is unneeded.
This patch redefines NCHUNKS to 63 as free chunk number in one zbud page, hence
we can decrease size of zpool and avoid accessing the last unused freelist
whenever failing to allocate zbud from freelist in zbud_alloc.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
---
mm/zbud.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/mm/zbud.c b/mm/zbud.c
index f26e7fc..ecf1dbe 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -60,15 +60,17 @@
* NCHUNKS_ORDER determines the internal allocation granularity, effectively
* adjusting internal fragmentation. It also determines the number of
* freelists maintained in each pool. NCHUNKS_ORDER of 6 means that the
- * allocation granularity will be in chunks of size PAGE_SIZE/64, and there
- * will be 64 freelists per pool.
+ * allocation granularity will be in chunks of size PAGE_SIZE/64. As one chunk
+ * in allocated page is occupied by zbud header, NCHUNKS will be calculated to
+ * 63 which shows the max number of free chunks in zbud page, also there will be
+ * 63 freelists per pool.
*/
#define NCHUNKS_ORDER 6
#define CHUNK_SHIFT (PAGE_SHIFT - NCHUNKS_ORDER)
#define CHUNK_SIZE (1 << CHUNK_SHIFT)
-#define NCHUNKS (PAGE_SIZE >> CHUNK_SHIFT)
#define ZHDR_SIZE_ALIGNED CHUNK_SIZE
+#define NCHUNKS ((PAGE_SIZE - ZHDR_SIZE_ALIGNED) >> CHUNK_SHIFT)
/**
* struct zbud_pool - stores metadata for each zbud pool
@@ -268,10 +270,9 @@ static int num_free_chunks(struct zbud_header *zhdr)
{
/*
* Rather than branch for different situations, just use the fact that
- * free buddies have a length of zero to simplify everything. -1 at the
- * end for the zbud header.
+ * free buddies have a length of zero to simplify everything.
*/
- return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks - 1;
+ return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks;
}
/*****************
--
2.0.1.474.g72c7794
--
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>
reply other threads:[~2014-09-03 5:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='000001cfc73b$9340d050$b9c270f0$@samsung.com' \
--to=chao2.yu@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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