From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: next phase of tmem into linux-next Date: Wed, 1 Jun 2011 09:22:59 -0700 (PDT) Message-ID: References: <80f7ab04-7ae6-48cb-b254-e99343147bf0@default 20110601142544.62494a52.sfr@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Return-path: Received: from rcsinet10.oracle.com ([148.87.113.121]:21284 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756000Ab1FAQXj convert rfc822-to-8bit (ORCPT ); Wed, 1 Jun 2011 12:23:39 -0400 In-Reply-To: <20110601142544.62494a52.sfr@canb.auug.org.au> Sender: linux-next-owner@vger.kernel.org List-ID: To: Stephen Rothwell Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Konrad Wilk > On Tue, 31 May 2011 17:49:21 -0700 (PDT) Dan Magenheimer > wrote: > > > > Please re-include the following tree into linux-next. The > > commit series is for frontswap, the complement of cleancache > > handling swap pages, which is the next phase in tmem. It also > > includes the shim code to Xen tmem for frontswap. It applies > > cleanly on linux-3.0-rc1, but if there are any problems or > > you have any questions, please let me know! > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem.git#linux-next > > I don't remove trees from linux-next unless excplictly asked to, so > this > tree is still included Hi Stephen -- OK, I see "Already up-to-date" in merge.log. I'll assume that the new frontswap commits will lag a day. (Thanks, Konrad, for helping me find this info and pointing out the probable lag.) (A thought... perhaps the merge.log generation script should do a "date" at the beginning and end, so one knows if one has just missed your merge window?) > As long as you stick to the rules (posted, > reviewed, ready for Linus), anything you add to that tree will be > included. Yep, understood. Frontswap has been posted on lkml and tested for over a year (and for nearly 2-1/2 years if counting earlier versions as part of the original tmem postings), but hasn't gotten as much attention because it was serialized behind merging of cleancache. > The tree is still called "cleancache" in linux-next. Should I change > that to something more generic? Yes please. A good short name would be "tmem", but if you want something longer and more descriptive maybe, "transcendent_memory". I expect in the future that this might be the path for, for example, tmem-related code that is promoted from drivers/staging. E.g., the generic tmem.c code in drivers/staging/zcache could probably end up in lib at some point if/when there are multiple users. Thanks! Dan