From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx170.postini.com [74.125.245.170]) by kanga.kvack.org (Postfix) with SMTP id 668796B0002 for ; Tue, 19 Feb 2013 10:27:55 -0500 (EST) MIME-Version: 1.0 Message-ID: <1f089254-3abe-4c63-a72a-c9e564ae7d0d@default> Date: Tue, 19 Feb 2013 07:27:24 -0800 (PST) From: Dan Magenheimer Subject: RE: Questin about swap_slot free and invalidate page References: <20130131051140.GB23548@blaptop> <20130204024950.GD2688@blaptop> <51236C11.1010208@gmail.com> In-Reply-To: <51236C11.1010208@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Ric Mason Cc: Minchan Kim , Hugh Dickins , Nitin Gupta , Seth Jennings , Konrad Rzeszutek Wilk , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton > From: Ric Mason [mailto:ric.masonn@gmail.com] > Sent: Tuesday, February 19, 2013 5:12 AM > To: Dan Magenheimer > Cc: Minchan Kim; Hugh Dickins; Nitin Gupta; Seth Jennings; Konrad Rzeszut= ek Wilk; linux-mm@kvack.org; > linux-kernel@vger.kernel.org; Andrew Morton > Subject: Re: Questin about swap_slot free and invalidate page >=20 > On 02/05/2013 05:28 AM, Dan Magenheimer wrote: > >> From: Minchan Kim [mailto:minchan@kernel.org] > >> Sent: Sunday, February 03, 2013 7:50 PM > >> To: Hugh Dickins > >> Cc: Nitin Gupta; Dan Magenheimer; Seth Jennings; Konrad Rzeszutek Wilk= ; linux-mm@kvack.org; linux- > >> kernel@vger.kernel.org; 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 da= ta 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 overwrit= ing of > >>>> data shouldn't happen in frontswap. > >>>> > >> I am waiting Dan's reply(He will come in this week) and then, judge wh= at'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 >=20 > Which ABI in zcache implement that? https://oss.oracle.com/projects/tmem/dist/documentation/api/tmemspec-v001.p= df The in-kernel APIs are frontswap and cleancache. For more information abou= t tmem, see http://lwn.net/Articles/454795/=20 =20 > > 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, 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: email@kvack.org