From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Seth Jennings <spartacus06@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Bob Liu <bob.liu@oracle.com>, Mel Gorman <mgorman@suse.de>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Tomasz Stanislawski <t.stanislaws@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Dave Hansen <dave.hansen@intel.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH v3 5/6] zswap: replace tree in zswap with radix tree in zbud
Date: Thu, 10 Oct 2013 09:01:24 +0200 [thread overview]
Message-ID: <1381388484.21461.16.camel@AMDC1943> (raw)
In-Reply-To: <20131009171617.GA21057@variantweb.net>
On Wed, 2013-10-09 at 12:16 -0500, Seth Jennings wrote:
> On Wed, Oct 09, 2013 at 10:30:22AM -0500, Seth Jennings wrote:
> > In my approach, I was also looking at allowing the zbud pools to use
> > HIGHMEM pages, since the handle is no longer an address. This requires
> > the pages that are being mapped to be kmapped (atomic) which will
> > disable preemption. This isn't an additional overhead since the
> > map/unmap corresponds with a compress/decompress operation at the zswap
> > level which uses per-cpu variables that disable preemption already.
>
> On second though, lets not mess with the HIGHMEM page support for now.
> Turns out it is tricker than I thought since the unbuddied lists are
> linked through the zbud header stored in the page. But we can still
> disable preemption to allow per-cpu tracking of the current mapping and
> avoid a lookup (and races) in zbud_unmap().
This tracking of current mapping could solve another problem I
encountered with new one-radix-tree approach with storage of duplicated
entries.
The problem is in zbud_unmap() API using offset to unmap (if duplicated
entries are overwritten):
- thread 1: zswap_fronstwap_load() of some offset
- zbud_map() maps this offset -> zhdr1
- thread 2: zswap_frontswap_store() stores new data for this offset
- zbud_alloc() allocated new zhdr2 and replaces zhdr1 in radix tree
under this offset
- new compressed data is stored by zswap
- thread 1: tries to zbud_unmap() of this offset, but now the old
zhdr1 is not present in radix tree so unmap will either fail or use
zhdr2 which is wrong
To solve this issue I experimented with unmapping by zbud_mapped_entry
instead of offset (so zbud_unmap() won't search zbud_header in radix
tree at all):
##########################
int zbud_unmap(struct zbud_pool *pool, pgoff_t offset,
struct zbud_mapped_entry *entry)
{
struct zbud_header *zhdr = handle_to_zbud_header((unsigned
long)entry->addr);
VM_BUG_ON((offset != zhdr->first_offset) && (offset !=
zhdr->last_offset));
spin_lock(&pool->lock);
if (put_map_count(zhdr, offset)) {
/* Racing zbud_free() could not free the offset because
* it was still mapped so it is our job to free. */
zbud_header_free(pool, zhdr, offset);
spin_unlock(&pool->lock);
return -EFAULT;
}
put_zbud_page(zhdr);
spin_unlock(&pool->lock);
return 0;
}
##########################
However getting rid of first/last_map_count seems much more simpler!
Best regards,
Krzysztof
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Seth Jennings <spartacus06@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Bob Liu <bob.liu@oracle.com>, Mel Gorman <mgorman@suse.de>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Tomasz Stanislawski <t.stanislaws@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Dave Hansen <dave.hansen@intel.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH v3 5/6] zswap: replace tree in zswap with radix tree in zbud
Date: Thu, 10 Oct 2013 09:01:24 +0200 [thread overview]
Message-ID: <1381388484.21461.16.camel@AMDC1943> (raw)
In-Reply-To: <20131009171617.GA21057@variantweb.net>
On Wed, 2013-10-09 at 12:16 -0500, Seth Jennings wrote:
> On Wed, Oct 09, 2013 at 10:30:22AM -0500, Seth Jennings wrote:
> > In my approach, I was also looking at allowing the zbud pools to use
> > HIGHMEM pages, since the handle is no longer an address. This requires
> > the pages that are being mapped to be kmapped (atomic) which will
> > disable preemption. This isn't an additional overhead since the
> > map/unmap corresponds with a compress/decompress operation at the zswap
> > level which uses per-cpu variables that disable preemption already.
>
> On second though, lets not mess with the HIGHMEM page support for now.
> Turns out it is tricker than I thought since the unbuddied lists are
> linked through the zbud header stored in the page. But we can still
> disable preemption to allow per-cpu tracking of the current mapping and
> avoid a lookup (and races) in zbud_unmap().
This tracking of current mapping could solve another problem I
encountered with new one-radix-tree approach with storage of duplicated
entries.
The problem is in zbud_unmap() API using offset to unmap (if duplicated
entries are overwritten):
- thread 1: zswap_fronstwap_load() of some offset
- zbud_map() maps this offset -> zhdr1
- thread 2: zswap_frontswap_store() stores new data for this offset
- zbud_alloc() allocated new zhdr2 and replaces zhdr1 in radix tree
under this offset
- new compressed data is stored by zswap
- thread 1: tries to zbud_unmap() of this offset, but now the old
zhdr1 is not present in radix tree so unmap will either fail or use
zhdr2 which is wrong
To solve this issue I experimented with unmapping by zbud_mapped_entry
instead of offset (so zbud_unmap() won't search zbud_header in radix
tree at all):
##########################
int zbud_unmap(struct zbud_pool *pool, pgoff_t offset,
struct zbud_mapped_entry *entry)
{
struct zbud_header *zhdr = handle_to_zbud_header((unsigned
long)entry->addr);
VM_BUG_ON((offset != zhdr->first_offset) && (offset !=
zhdr->last_offset));
spin_lock(&pool->lock);
if (put_map_count(zhdr, offset)) {
/* Racing zbud_free() could not free the offset because
* it was still mapped so it is our job to free. */
zbud_header_free(pool, zhdr, offset);
spin_unlock(&pool->lock);
return -EFAULT;
}
put_zbud_page(zhdr);
spin_unlock(&pool->lock);
return 0;
}
##########################
However getting rid of first/last_map_count seems much more simpler!
Best regards,
Krzysztof
next prev parent reply other threads:[~2013-10-10 7:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 13:29 [PATCH v3 0/6] mm: migrate zbud pages Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-08 13:29 ` [PATCH v3 1/6] zbud: use page ref counter for " Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-08 20:43 ` Seth Jennings
2013-10-09 7:08 ` Krzysztof Kozlowski
2013-10-09 7:08 ` Krzysztof Kozlowski
2013-10-08 13:29 ` [PATCH v3 2/6] zbud: make freechunks a block local variable Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-08 20:46 ` Seth Jennings
2013-10-08 13:29 ` [PATCH v3 3/6] mm: use mapcount for identifying zbud pages Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-08 13:29 ` [PATCH v3 4/6] zbud: memset zbud_header to 0 during init Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-08 20:48 ` Seth Jennings
2013-10-08 13:29 ` [PATCH v3 5/6] zswap: replace tree in zswap with radix tree in zbud Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
2013-10-09 15:30 ` Seth Jennings
2013-10-09 15:30 ` Seth Jennings
2013-10-09 17:16 ` Seth Jennings
2013-10-09 17:16 ` Seth Jennings
2013-10-10 7:01 ` Krzysztof Kozlowski [this message]
2013-10-10 7:01 ` Krzysztof Kozlowski
2013-10-08 13:29 ` [PATCH v3 6/6] mm: migrate zbud pages Krzysztof Kozlowski
2013-10-08 13:29 ` Krzysztof Kozlowski
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=1381388484.21461.16.camel@AMDC1943 \
--to=k.kozlowski@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=b.zolnierkie@samsung.com \
--cc=bob.liu@oracle.com \
--cc=dave.hansen@intel.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=spartacus06@gmail.com \
--cc=t.stanislaws@samsung.com \
/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 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.