Re: [PATCH 4/7] zram/xvmalloc: free bit block insertionoptimization

From: Robert Jennings
Date: Wed Jan 26 2011 - 13:42:52 EST


* Pekka Enberg (penberg@xxxxxxxxxx) wrote:
> On Wed, Jan 26, 2011 at 7:25 PM, Robert Jennings <rcj@xxxxxxxxxxxxxxxxxx> wrote:
> > There is no need to set the bits in the first- and second-level indices
> > to indicate a free page when we know that a free page existed at this
> > level.
> >
> > Signed-off-by: Robert Jennings <rcj@xxxxxxxxxxxxxxxxxx>
>
> Why is it not necessary? I don't know that part of the code well
> enough to tell if this patch is safe or not.

This change is in a conditional block which is entered only when there is
an existing data block on the freelist where the insert has taken place.

The new block is pushed onto the freelist stack and this conditional block
is updating links in the prior stack head to point to the new stack head.
After this conditional block the first-/second-level indices are updated
to indicate that there is a free block at this location.

This patch adds an immediate return from the conditional block to avoid
setting bits again to indicate a free block on this freelist. They would
already be set because there was an existing free block on this freelist.

> > ---
> >  drivers/staging/zram/xvmalloc.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/staging/zram/xvmalloc.c b/drivers/staging/zram/xvmalloc.c
> > index a507f95..b3622f1 100644
> > --- a/drivers/staging/zram/xvmalloc.c
> > +++ b/drivers/staging/zram/xvmalloc.c
> > @@ -205,6 +205,8 @@ static void insert_block(struct xv_pool *pool, struct page *page, u32 offset,
> >                nextblock->link.prev_page = page;
> >                nextblock->link.prev_offset = offset;
> >                put_ptr_atomic(nextblock, KM_USER1);
> > +               /* If there was a next page then the free bits are set. */
> > +               return;
> >        }
> >
> >        __set_bit(slindex % BITS_PER_LONG, &pool->slbitmap[flindex]);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/