Re: Questin about swap_slot free and invalidate page

From: Ric Mason
Date: Tue Feb 19 2013 - 21:04:10 EST

On 02/19/2013 11:27 PM, Dan Magenheimer wrote:
From: Ric Mason [mailto:ric.masonn@xxxxxxxxx]
Sent: Tuesday, February 19, 2013 5:12 AM
To: Dan Magenheimer
Cc: Minchan Kim; Hugh Dickins; Nitin Gupta; Seth Jennings; Konrad Rzeszutek Wilk; linux-mm@xxxxxxxxx;
linux-kernel@xxxxxxxxxxxxxxx; Andrew Morton
Subject: Re: Questin about swap_slot free and invalidate page

On 02/05/2013 05:28 AM, Dan Magenheimer wrote:
From: Minchan Kim [mailto:minchan@xxxxxxxxxx]
Sent: Sunday, February 03, 2013 7:50 PM
To: Hugh Dickins
Cc: Nitin Gupta; Dan Magenheimer; Seth Jennings; Konrad Rzeszutek Wilk; linux-mm@xxxxxxxxx; linux-
kernel@xxxxxxxxxxxxxxx; Andrew Morton
Subject: Re: Questin about swap_slot free and invalidate page

Hi Hugh,

On Sun, Feb 03, 2013 at 05:51:14PM -0800, Hugh Dickins wrote:
On Thu, 31 Jan 2013, Minchan Kim wrote:

When I reviewed zswap, I was curious about frontswap_store.
It said following as.

* If frontswap already contains a page with matching swaptype and
* offset, the frontswap implementation may either overwrite the data and
* return success or invalidate the page from frontswap and return failure.

It didn't say why it happens. we already have __frontswap_invalidate_page
and call it whenever swap_slot frees. If we don't free swap slot,
scan_swap_map can't find the slot for swap out so I thought overwriting of
data shouldn't happen in frontswap.

I am waiting Dan's reply(He will come in this week) and then, judge what's
the best.
Hugh is right that handling the possibility of duplicates is
part of the tmem ABI. If there is any possibility of duplicates,
the ABI defines how a backend must handle them to avoid data
coherency issues.

The kernel implements an in-kernel API which implements the tmem
ABI. If the frontend and backend can always agree that duplicate
Which ABI in zcache implement that?

The in-kernel APIs are frontswap and cleancache. For more information about
tmem, see

But you mentioned that you have in-kernel API which can handle duplicate. Do you mean zcache_cleancache/frontswap_put_page? I think they just overwrite instead of optional flush the page on the second(duplicate) put as mentioned in your tmemspec.

are never possible, I agree that the backend could avoid that
special case. However, duplicates occur rarely enough and the
consequences (data loss) are bad enough that I think the case
should still be checked, at least with a BUG_ON. I also wonder
if it is worth it to make changes to the core swap subsystem
to avoid code to implement a zswap corner case.

Remember that zswap is an oversimplified special case of tmem
that handles only one frontend (Linux frontswap) and one backend
(zswap). Tmem goes well beyond that and already supports other
more general backends including Xen and ramster, and could also
support other frontends such as a BSD or Solaris equivalent
of frontswap, for example with a Linux ramster/zcache backend.
I'm not sure how wise it is to tear out generic code and replace
it with simplistic code unless there is absolutely no chance that
the generic code will be necessary.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at