From: Robert Jennings <rcj@linux.vnet.ibm.com>
To: Nitin Gupta <ngupta@vflare.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
Robert Jennings <rcj@linux.vnet.ibm.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: [PATCH 7/7] zram/xvmalloc: combine duplicate block delete code
Date: Fri, 28 Jan 2011 09:01:55 -0600 [thread overview]
Message-ID: <20110128150155.GH2062@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110128145602.GA2062@linux.vnet.ibm.com>
This patch eliminates duplicate code. The remove_block_head function
is a special case of remove_block which can be contained in remove_block
without confusion.
The portion of code in remove_block_head which was noted as "DEBUG ONLY"
is now mandatory. Doing this provides consistent management of the double
linked list of blocks under a freelist and makes this consolidation
of delete block code safe. The first and last blocks will have NULL
pointers in their previous and next page pointers respectively.
Additionally, any time a block is removed from a free list the next and
previous pointers will be set to NULL to avoid misuse outside xvmalloc.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
drivers/staging/zram/xvmalloc.c | 73 ++++++++++++++++----------------------
1 files changed, 31 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/zram/xvmalloc.c b/drivers/staging/zram/xvmalloc.c
index 0560e9d..fc4a3df 100644
--- a/drivers/staging/zram/xvmalloc.c
+++ b/drivers/staging/zram/xvmalloc.c
@@ -213,54 +213,14 @@ static void insert_block(struct xv_pool *pool, struct page *page, u32 offset,
}
/*
- * Remove block from head of freelist. Index 'slindex' identifies the freelist.
- */
-static void remove_block_head(struct xv_pool *pool,
- struct block_header *block, u32 slindex)
-{
- struct block_header *tmpblock;
- u32 flindex = slindex / BITS_PER_LONG;
-
- pool->freelist[slindex].page = block->link.next_page;
- pool->freelist[slindex].offset = block->link.next_offset;
- block->link.prev_page = NULL;
- block->link.prev_offset = 0;
-
- if (!pool->freelist[slindex].page) {
- __clear_bit(slindex % BITS_PER_LONG, &pool->slbitmap[flindex]);
- if (!pool->slbitmap[flindex])
- __clear_bit(flindex, &pool->flbitmap);
- } else {
- /*
- * DEBUG ONLY: We need not reinitialize freelist head previous
- * pointer to 0 - we never depend on its value. But just for
- * sanity, lets do it.
- */
- tmpblock = get_ptr_atomic(pool->freelist[slindex].page,
- pool->freelist[slindex].offset, KM_USER1);
- tmpblock->link.prev_page = NULL;
- tmpblock->link.prev_offset = 0;
- put_ptr_atomic(tmpblock, KM_USER1);
- }
-}
-
-/*
* Remove block from freelist. Index 'slindex' identifies the freelist.
*/
static void remove_block(struct xv_pool *pool, struct page *page, u32 offset,
struct block_header *block, u32 slindex)
{
- u32 flindex;
+ u32 flindex = slindex / BITS_PER_LONG;
struct block_header *tmpblock;
- if (pool->freelist[slindex].page == page
- && pool->freelist[slindex].offset == offset) {
- remove_block_head(pool, block, slindex);
- return;
- }
-
- flindex = slindex / BITS_PER_LONG;
-
if (block->link.prev_page) {
tmpblock = get_ptr_atomic(block->link.prev_page,
block->link.prev_offset, KM_USER1);
@@ -276,6 +236,35 @@ static void remove_block(struct xv_pool *pool, struct page *page, u32 offset,
tmpblock->link.prev_offset = block->link.prev_offset;
put_ptr_atomic(tmpblock, KM_USER1);
}
+
+ /* Is this block is at the head of the freelist? */
+ if (pool->freelist[slindex].page == page
+ && pool->freelist[slindex].offset == offset) {
+
+ pool->freelist[slindex].page = block->link.next_page;
+ pool->freelist[slindex].offset = block->link.next_offset;
+
+ if (pool->freelist[slindex].page) {
+ struct block_header *tmpblock;
+ tmpblock = get_ptr_atomic(pool->freelist[slindex].page,
+ pool->freelist[slindex].offset,
+ KM_USER1);
+ tmpblock->link.prev_page = NULL;
+ tmpblock->link.prev_offset = 0;
+ put_ptr_atomic(tmpblock, KM_USER1);
+ } else {
+ /* This freelist bucket is empty */
+ __clear_bit(slindex % BITS_PER_LONG,
+ &pool->slbitmap[flindex]);
+ if (!pool->slbitmap[flindex])
+ __clear_bit(flindex, &pool->flbitmap);
+ }
+ }
+
+ block->link.prev_page = NULL;
+ block->link.prev_offset = 0;
+ block->link.next_page = NULL;
+ block->link.next_offset = 0;
}
/*
@@ -384,7 +373,7 @@ int xv_malloc(struct xv_pool *pool, u32 size, struct page **page,
block = get_ptr_atomic(*page, *offset, KM_USER0);
- remove_block_head(pool, block, index);
+ remove_block(pool, *page, *offset, block, index);
/* Split the block if required */
tmpoffset = *offset + size + XV_ALIGN;
--
1.7.0.4
next prev parent reply other threads:[~2011-01-28 15:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-28 14:56 [PATCH 0/7][v2] zram/xvmalloc: 64K page fixes and optimizations Robert Jennings
2011-01-28 14:57 ` [PATCH 1/7] [v2] zram/vmalloc: Correct tunings to enable use with 64K pages Robert Jennings
2011-01-29 8:47 ` Pekka Enberg
2011-01-28 14:58 ` [PATCH 2/7] [v2] zram: Prevent overflow in logical block size Robert Jennings
2011-01-29 8:48 ` Pekka Enberg
2011-01-28 14:58 ` [PATCH 3/7] [v2] zram/xvmalloc: free bit block insertion optimization Robert Jennings
2011-01-29 8:48 ` Pekka Enberg
2011-01-28 14:59 ` [PATCH 4/7] [v2] zram/xvmalloc: create CONFIG_ZRAM_DEBUG for debug code Robert Jennings
2011-01-29 8:48 ` Pekka Enberg
2011-01-28 15:00 ` [PATCH 5/7] [v2] zram/xvmalloc: Close 32byte hole on 64bit CPUs Robert Jennings
2011-01-29 8:49 ` Pekka Enberg
2011-01-28 15:00 ` [PATCH 6/7] zram: Return zero'd pages on new reads Robert Jennings
2011-01-29 8:49 ` Pekka Enberg
2011-01-28 15:01 ` Robert Jennings [this message]
2011-01-29 8:50 ` [PATCH 7/7] zram/xvmalloc: combine duplicate block delete code Pekka Enberg
2011-01-31 13:31 ` Nitin Gupta
2011-01-29 8:47 ` [PATCH 0/7][v2] zram/xvmalloc: 64K page fixes and optimizations Pekka Enberg
2011-01-29 18:54 ` Robert Jennings
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=20110128150155.GH2062@linux.vnet.ibm.com \
--to=rcj@linux.vnet.ibm.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ngupta@vflare.org \
--cc=penberg@cs.helsinki.fi \
/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