* [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls
@ 2013-11-20 19:47 Dan Streetman
2013-11-21 2:52 ` Weijie Yang
0 siblings, 1 reply; 3+ messages in thread
From: Dan Streetman @ 2013-11-20 19:47 UTC (permalink / raw)
To: Seth Jennings
Cc: Dan Streetman, linux-mm, linux-kernel, Bob Liu, Minchan Kim, Weijie Yang
Since zswap_rb_erase was added to the final (when refcount == 0)
zswap_put_entry, there is no need to call zswap_rb_erase before
calling zswap_put_entry.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
---
mm/zswap.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index e154f1e..f4fbbd5 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -711,8 +711,6 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
ret = zswap_rb_insert(&tree->rbroot, entry, &dupentry);
if (ret == -EEXIST) {
zswap_duplicate_entry++;
- /* remove from rbtree */
- zswap_rb_erase(&tree->rbroot, dupentry);
zswap_entry_put(tree, dupentry);
}
} while (ret == -EEXIST);
@@ -787,9 +785,6 @@ static void zswap_frontswap_invalidate_page(unsigned type, pgoff_t offset)
return;
}
- /* remove from rbtree */
- zswap_rb_erase(&tree->rbroot, entry);
-
/* drop the initial reference from entry creation */
zswap_entry_put(tree, entry);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls
2013-11-20 19:47 [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls Dan Streetman
@ 2013-11-21 2:52 ` Weijie Yang
2013-11-21 22:33 ` Dan Streetman
0 siblings, 1 reply; 3+ messages in thread
From: Weijie Yang @ 2013-11-21 2:52 UTC (permalink / raw)
To: Dan Streetman
Cc: Seth Jennings, linux-mm, linux-kernel, Bob Liu, Minchan Kim, Weijie Yang
Hello Dan
On Thu, Nov 21, 2013 at 3:47 AM, Dan Streetman <ddstreet@ieee.org> wrote:
> Since zswap_rb_erase was added to the final (when refcount == 0)
> zswap_put_entry, there is no need to call zswap_rb_erase before
> calling zswap_put_entry.
>
> Signed-off-by: Dan Streetman <ddstreet@ieee.org>
> ---
> mm/zswap.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index e154f1e..f4fbbd5 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -711,8 +711,6 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
> ret = zswap_rb_insert(&tree->rbroot, entry, &dupentry);
> if (ret == -EEXIST) {
> zswap_duplicate_entry++;
> - /* remove from rbtree */
> - zswap_rb_erase(&tree->rbroot, dupentry);
> zswap_entry_put(tree, dupentry);
> }
> } while (ret == -EEXIST);
If remove zswap_rb_erase, it would loop until free this dupentry. This
would cause 2 proplems:
1. zswap_duplicate_entry counter is not correct
2. trigger BUG_ON in zswap_entry_put when this dupentry is being writeback,
because zswap_writeback_entry will call zswap_entry_put either.
So, I don't think it is a good idea to remove zswap_rb_erase call.
> @@ -787,9 +785,6 @@ static void zswap_frontswap_invalidate_page(unsigned type, pgoff_t offset)
> return;
> }
>
> - /* remove from rbtree */
> - zswap_rb_erase(&tree->rbroot, entry);
> -
> /* drop the initial reference from entry creation */
> zswap_entry_put(tree, entry);
I think it is better not to remove the zswap_rb_erase call.
>From frontswap interface view, if invalidate is called, the page(and
entry) should never visible to upper.
If remove the zswap_rb_erase call, it is not fit this semantic.
Consider the following scenario:
1. thread 0: entry A is being writeback
2. thread 1: invalidate entry A, as refcount != 0, it will still exist
on rbtree.
3. thread 1: reuse entry A 's swp_entry_t, do a frontswap_store
it will conflict with the entry A on the rbtree, it is not a
normal duplicate store.
If we place the zswap_rb_erase call in zswap_frontswap_invalidate_page,
we can avoid the above scenario.
So, I don't think it is a good idea to remove zswap_rb_erase call.
Regards,
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls
2013-11-21 2:52 ` Weijie Yang
@ 2013-11-21 22:33 ` Dan Streetman
0 siblings, 0 replies; 3+ messages in thread
From: Dan Streetman @ 2013-11-21 22:33 UTC (permalink / raw)
To: Weijie Yang
Cc: Seth Jennings, linux-mm, linux-kernel, Bob Liu, Minchan Kim, Weijie Yang
On Wed, Nov 20, 2013 at 9:52 PM, Weijie Yang <weijie.yang.kh@gmail.com> wrote:
> Hello Dan
>
> On Thu, Nov 21, 2013 at 3:47 AM, Dan Streetman <ddstreet@ieee.org> wrote:
>> Since zswap_rb_erase was added to the final (when refcount == 0)
>> zswap_put_entry, there is no need to call zswap_rb_erase before
>> calling zswap_put_entry.
>>
>> Signed-off-by: Dan Streetman <ddstreet@ieee.org>
>> ---
>> mm/zswap.c | 5 -----
>> 1 file changed, 5 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index e154f1e..f4fbbd5 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -711,8 +711,6 @@ static int zswap_frontswap_store(unsigned type, pgoff_t offset,
>> ret = zswap_rb_insert(&tree->rbroot, entry, &dupentry);
>> if (ret == -EEXIST) {
>> zswap_duplicate_entry++;
>> - /* remove from rbtree */
>> - zswap_rb_erase(&tree->rbroot, dupentry);
>> zswap_entry_put(tree, dupentry);
>> }
>> } while (ret == -EEXIST);
>
> If remove zswap_rb_erase, it would loop until free this dupentry. This
> would cause 2 proplems:
I need to get more familiar with when it's possible to hit a duplicate
entry, it seems strange to me that higher level swap code would be
trying to store a page with an already used offset.
> 1. zswap_duplicate_entry counter is not correct
> 2. trigger BUG_ON in zswap_entry_put when this dupentry is being writeback,
> because zswap_writeback_entry will call zswap_entry_put either.
>
> So, I don't think it is a good idea to remove zswap_rb_erase call.
>
>> @@ -787,9 +785,6 @@ static void zswap_frontswap_invalidate_page(unsigned type, pgoff_t offset)
>> return;
>> }
>>
>> - /* remove from rbtree */
>> - zswap_rb_erase(&tree->rbroot, entry);
>> -
>> /* drop the initial reference from entry creation */
>> zswap_entry_put(tree, entry);
>
> I think it is better not to remove the zswap_rb_erase call.
>
> From frontswap interface view, if invalidate is called, the page(and
> entry) should never visible to upper.
> If remove the zswap_rb_erase call, it is not fit this semantic.
>
> Consider the following scenario:
> 1. thread 0: entry A is being writeback
> 2. thread 1: invalidate entry A, as refcount != 0, it will still exist
> on rbtree.
> 3. thread 1: reuse entry A 's swp_entry_t, do a frontswap_store
> it will conflict with the entry A on the rbtree, it is not a
> normal duplicate store.
>
> If we place the zswap_rb_erase call in zswap_frontswap_invalidate_page,
> we can avoid the above scenario.
>
> So, I don't think it is a good idea to remove zswap_rb_erase call.
It seems to me that zswap_rb_erase shouldn't have been folded into
zswap_entry_put; if it was removed now, the only place it would need
to be added back is into the success path of writeback, i.e.:
if (entry == zswap_rb_search(&tree->rbroot, offset)) {
zswap_rb_erase(&tree->rbroot, entry);
zswap_entry_put(tree, entry);
}
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-11-21 22:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-20 19:47 [PATCH] mm/zswap: remove unneeded zswap_rb_erase calls Dan Streetman
2013-11-21 2:52 ` Weijie Yang
2013-11-21 22:33 ` Dan Streetman
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).